Neja Ready

Compile past yacht-charter communication histories into an evidence-linked readiness protocol for the next departure.

Neja Ready is a local, zero-dependency Build Week prototype. Its default judge path replays an immutable historical GPT-5.6 Sol response without making a new provider call. That receipt predates the current adapter contract and is not current-adapter proof. A clearly labeled synthetic replay fixture is available only as a secondary product demo. Neither path needs credentials, customer data, payment, scheduling, or message sending.

The judge delivery artifact is the exact tree tracked by Git at the submitted public commit. Obtain it through a clean clone or the Git host's source archive. It is not an npm package: npm pack is not part of the delivery contract.

Why it matters

A confirmed yacht charter triggers a dependency-rich sequence: payments, identity documents, arrival plans, preferences, provisioning, packing and safety, marina handoff, race briefing, and follow-up. At small seasonal fleets, the operational playbook can be split across old emails, chat threads, spreadsheets, booking records, and the memory of senior staff.

Existing charter platforms can automate a journey after someone has configured it. Neja addresses the preceding job: recover the actual protocol from several past runs, distinguish invariant intent from variable facts, expose conflicts, and compile a new run without copying an unsupported location, time, or policy.

The market evidence and its limitations are documented in the private submission workspace. The public prototype makes no production-impact or ROI claim.

What it does

On the committed synthetic fixture, deterministic product code:

1. Reads three fictional historical charter traces containing 27 messages.
2. Reconstructs nine recurring readiness steps with exact source IDs.
3. Surfaces three cross-run policy conflicts.
4. Compiles an incomplete Greece 2026 charter and blocks three downstream steps.
5. Shows the structural impact of three questions against the fixture graph.
6. Recompiles after verified brief answers.
7. Runs deterministic source, fact, dependency, date, and claim checks.
8. Requires a recorded human approval and stops. It never sends a message.

The central artifact is a source-linked readiness protocol and evidence matrix—not a collection of AI-written messages.

Judge delivery and path

Use a clean clone or Git-host source archive of the exact submitted commit. The tracked tree includes the accepted recorded-proof JSON under artifacts/gpt56-proof/; ignored raw/private proof runs are not delivery artifacts.

No hosted app, npm package, account, API key, or provider call is required.

1. Open the app and keep the default Recorded GPT-5.6 proof mode selected.
2. Click Reconstruct readiness protocol. Confirm that the historical card is limited to nine steps with relevant exact sources, three seeded conflicts, and grouping of five explicitly supplied missing fields.
3. Confirm that the card labels current-adapter execution NOT PROVEN, then select the secondary Synthetic fixture demo and reconstruct again.
4. Click Review 3 blockers and resolve the questions with the fictional verified brief answers.
5. Confirm the deterministic fixture recompiles from three blocked steps to zero and inspect the structural-impact ordering, then click Review timeline.
6. Open a timeline card to inspect its required facts and source lineage, then click Review preflight.
7. Confirm deterministic preflight moves to Ready for review.
8. Click Approve plan and confirm 0 messages sent.

The origin badge and proof card identify the immutable stored provider response, its untouched-output status, and store: false request. The accepted historical scope is deliberately narrow: nine steps, relevant exact sources, three seeded conflicts, and grouping of five explicitly supplied missing fields. It does not prove dependency correctness, question minimality, structural-impact ranking, or the 3 → 0 transition. Those are deterministic fixture behaviors. The replay makes no API call and is not current-adapter proof.

The complete path is designed to fit comfortably within three minutes.

Run locally

Requirements: Node.js 22 or newer; release CI is configured for Node.js 22 and 24. There are no package dependencies, install step, or build step. Do not run npm install or npm pack for the judge path.

From the root of the clean clone or extracted tracked source archive:

npm start

Open http://127.0.0.1:4173.

Run the complete release verification:

npm run verify

Release verification runs without provider credentials or calls. CI explicitly clears the owner-gate and provider-key variables. If either is intentionally present in the current shell, stop and use a clean shell before running the verifier.

Historical proof and owner-gated CLI tooling

The app contains a Responses API adapter using model gpt-5.6, strict structured outputs, store: false, bounded output, timeout handling, refusal handling, and deterministic validation. The browser UI and HTTP API expose no live-provider mode: they accept only the explicit recorded replay or synthetic fixture, and npm start never makes a provider call. Optional proof generation is a separate command-line workflow and remains owner-gated. Never commit a key.

Historical provider evidence status: PASS under the immutable historical adapter contract. The accepted project-specific response was returned as gpt-5.6-sol, completed successfully, and required no manual repair. It demonstrated nine steps with relevant exact sources, three seeded conflicts, and grouping of five explicitly supplied missing fields. Its accepted protocol and receipt are committed under artifacts/gpt56-proof/; the UI can replay them without a secret or new call.

Current adapter provider proof: NOT_PROVEN — NOT_CLAIMED for the blind DTO. Blind-DTO hardening changed the adapter contract after that accepted run. No new provider call is authorized or required for the local recorded-proof judge path, so the historical receipt and hashes remain immutable and must not be presented as proof of current-adapter output. The synthetic fixture remains separately labeled and is not provider evidence. Identical request bytes cannot upgrade this state: current-adapter provider proof remains permanently NOT_PROVEN — NOT_CLAIMED. Current-adapter dependency quality, question minimality, and structural-impact ranking are likewise not proven.

Two owner-authorized historical calls were used. The first valid response did not satisfy the frozen acceptance check. After a prompt-only clarification, the second untouched response satisfied the archived receipt. The public evidence claim remains limited to the four facts above. No more provider calls are authorized or needed.

Fingerprint the current project-specific request contract without making a provider call:

npm run proof:gpt56:dry

The optional CLI evidence command may run only after a new, explicit owner authorization for that provider call. The historical run used:

NEJA_ALLOW_LIVE=1 OPENAI_API_KEY=your_key npm run proof:gpt56

The proof runner fingerprints the request, corpus, charter, and schema; stores the provider response metadata and untouched structured protocol; runs the archived acceptance check; records manualRepairPerformed: false and messagesSent: false; and exits non-zero on a failed receipt. Generated JSON remains ignored until a human reviews it. Only the immutable, secret-scanned historical protocol and receipt were intentionally added; their public evidence scope remains the four facts above, and they must not be rewritten to fit the current adapter.

Architecture and trust boundaries

synthetic histories + incomplete new charter
                    │
                    ▼
       GPT-5.6 semantic proposer,
       recorded proof, or labeled fixture replay
                    │ untrusted protocol proposal
                    ▼
 deterministic source / fact / dependency / date validators
                    │
                    ▼
 readiness matrix + blocking questions + compiled timeline
                    │
                    ▼
             human approval
                    │
                    └── STOP (no scheduler, no sender)

Authority is deliberately split:

• The current GPT-5.6 adapter is intended to propose semantic archetypes, dependencies, conflicts, blocking questions, and source-backed draft templates; its execution and dependency/impact quality remain unproven.
• Product code decides whether source IDs exist, required facts are present, dependencies are satisfied, dates are computable, and preflight passes.
• The human resolves conflicts and approves the plan.
• No actor in this prototype schedules or sends communications.

Authorship and tools

Demid selected the product direction, scope, public claims, and external gates. Codex assisted with research, product and fixture design, implementation, testing, browser QA, documentation, and the release audit. Demid reviewed the evidence and verified the AI-assisted implementation before release.

Demid retained these product decisions:

• pursue a second, independent Build Week project;
• start from repeated operational communications;
• use yacht trips and regattas as the demonstration domain;
• require explicit owner gates for paid calls and every external publication.

Codex contributed by:

• reading and following the launchpad contract;
• researching the official rubric, public judge statements, business evidence, and competitors;
• rejecting the generic message-planner framing;
• defining the charter-readiness wedge and evidence boundaries;
• authoring the synthetic corpus and hidden ground truth;
• implementing the compiler, validators, provider adapter, UI, server, tests, and release checks;
• keeping unsupported impact claims and external actions gated.

The current GPT-5.6 adapter's intended product role is:

• infer recurring readiness steps across noisy historical messages;
• separate invariant purpose from per-charter facts;
• cite exact message IDs;
• expose cross-run conflicts;
• group supplied missing facts into unblock questions;
• emit a strict typed proposal for deterministic verification.

A synthetic protocol fixture exercises the product contract locally. It is visibly labeled and is not presented as GPT-5.6 output. Deterministic fixture code demonstrates dependency checks, structural-impact ordering, and the 3 → 0 transition. Separately, an untouched historical project-specific GPT-5.6 Sol response demonstrated only nine steps with relevant exact sources, three seeded conflicts, and grouping of five explicitly supplied missing fields. It does not prove current-adapter execution, dependency correctness, question minimality, or impact ranking.

Safety, privacy, and operating limits

• All demo companies, people, trips, and messages are fictional.
• The server binds to 127.0.0.1 and has no database or account system.
• The browser server has no live-provider mode; optional CLI proof generation requires a separate explicit owner gate and keeps API keys out of the client.
• Provider output is untrusted and cannot approve itself.
• Invalid source IDs, fabricated excerpts, missing facts, dependency cycles, refusals, incomplete output, malformed JSON, and timeouts fail closed.
• There is no Telegram, email, WhatsApp, calendar, CRM, booking, payment, scheduling, or sending integration.
• The benchmark proves behavior only on the committed synthetic fixture.
• The accepted historical provider proof establishes one project-specific result limited to nine steps with relevant exact sources, three seeded conflicts, and grouping of five explicitly supplied missing fields—not dependency correctness, minimality, impact ranking, current-adapter proof, general model accuracy, or production reliability.
• Customer value, urgency, willingness to pay, adoption, time saved, ROI, and production impact remain UNKNOWN — NOT_CLAIMED. No interview or pilot is part of the submission evidence or judge path.

Build Week contribution and provenance

• Standalone product repository root commit: 4e7cafd87afac59a18638cf1eeaad8b95c99f75a, 2026-07-19T03:30:16+02:00. This standalone repository history is the independently inspectable provenance record for Neja's event-period implementation; public delivery remains a separate owner-authorized gate.
• Private launchpad before-state reference: 91764006d43ab12f09ba0f7c98fa5f3226cfbbe6, 2026-07-19T02:13:52+02:00. It belongs to the private operating workspace, is not an ancestor of this standalone repository, and is not a delivery artifact or public source URL.
• Qualifying work: all current Neja product code, fixtures, schemas, tests, UI, evidence, and story are new event-period work. Media is not part of this claim until a finished asset exists and its provenance is verified.
• Assets: first-party code and fictional text fixtures; no external visual or media asset.
• Excluded inputs: every artifact from other submissions and all real customer, messaging, passenger, and charter data.
• Neja requires a new project-specific /feedback Session ID.

Concrete contribution is separated by authority:

• Demid selected the product direction, scope, public claims, and every external-action gate.
• Codex performed the project research, product and fixture design, implementation, testing, browser QA, documentation, and release audit.
• GPT-5.6 proposed one project-specific semantic protocol from the fictional corpus; deterministic code evaluated it, and a human retains approval.

Testing

For deterministic fixture behavior, the release suite verifies:

• all ten seeded benchmark conditions;
• semantic step recovery independent of model-chosen IDs;
• relevant (not merely resolvable) fixture evidence;
• exact blocking-fact coverage and question grouping;
• initial blocked state and structural-impact ordering;
• the 3 → 0 transition after verified fixture facts;
• refusal to approve a blocked plan;
• zero-message approval behavior;
• rejection of invented source IDs and fabricated excerpts;
• rejection of undeclared facts and dependency cycles;
• end-to-end local compile and approval API;
• strict browser security/no-store headers.

Separately, the suite verifies provider-adapter refusal without credentials, fail-closed owner-gated CLI tooling, and immutable recorded receipt/protocol integrity. The historical semantic claim is limited to nine steps with relevant exact sources, three seeded conflicts, and grouping of five explicitly supplied missing fields. Tests do not establish current-adapter dependency quality, question minimality, structural-impact quality, customer impact, or general model accuracy.

Contributing

Keep contributions inside the same trust boundary: fictional data only, no credentials or private customer material, no message-sending integration, and no provider call from tests or release verification. Preserve the zero-dependency judge path unless a separately reviewed change updates the delivery contract and license record.

Before proposing a behavior change, add or update a focused regression test and run:

npm run verify

Do not commit raw provider runs, capture files, local environment files, or API keys. Document the license and source of any new dependency or external asset. Contributions to this repository are provided under the repository's MIT License.

License

MIT. See LICENSE.