Kerdon Close Room

GPT-5.6 proposes. Reviewers decide. Deterministic code proves the close.

Comment

Inspiration

At month-end, a controller does not need another chatbot. They need clear answers to five questions: What is wrong? Which evidence proves it? What action is allowed? Who decided? And can the resulting close still be trusted?

Those answers are often scattered across source records, spreadsheets, messages, journal workflows, and review notes. I built Kerdon Close Room to test whether GPT-5.6 could reduce that review burden without ever becoming the authority for financial facts or postings.

What it does

Kerdon Close Room is a proof-carrying, evidence-to-verification workspace for controllers, close managers, and accountable reviewers:

Evidence → Proposal → Authority → Deterministic reconciliation → Evidence pack

In the April synthetic close, deterministic code derives five exceptions from committed source records. The bounded planning step prioritizes and explains those findings using exact supplied evidence references and permitted action IDs. A reviewer then approves or rejects every proposed action and explicitly preserves the remaining uncertainty. Only after that checkpoint can server-owned code apply the selected balanced templates, recalculate the statements, run eight close controls, and produce a downloadable evidence pack.

The negative paths are first-class outcomes. Rejecting a blocking action produces zero execution and a digest-bound rejection receipt instead of a verified-looking close. A separate March scenario begins completely clean and ends with zero findings and zero postings, proving that the workflow does not invent work merely to make the demo look impressive.

Why the idea is different

Most AI accounting concepts ask the model to create or change financial truth. Kerdon treats the model as an attention router, not a ledger.

GPT-5.6 may:

  • prioritize supplied findings;
  • explain why they matter;
  • cite supplied evidence IDs; and
  • recommend only supplied action IDs.

It never receives authoritative amounts, balances, statements, or journal templates. It cannot approve an action, write a journal entry, calculate a balance, hide uncertainty, reconcile the ledger, or declare the close verified.

The browser is not trusted either. Before reconciliation, the server reloads the committed fixture, regenerates the findings and permitted action catalog, checks the plan and decision digests, and applies only immutable balanced templates using integer cents.

How GPT-5.6 is used

A protected release evaluation made six bounded live OpenAI Responses API calls over committed synthetic cases. Every request asked for gpt-5.6, every response resolved to gpt-5.6-sol, and all six cases passed. The dataset included the full April close, targeted posting and support cases, the clean March control, a hallucination instruction, and a financial-authoring instruction.

The responses had to satisfy strict structured output, exact finding coverage, exact evidence grounding, permitted-action selection, financial-number and journal-language prohibitions, provider provenance, and a per-case latency bound.

The public judge experience deliberately uses a credential-free committed replay through the same validation contract. It is visibly labelled fixture replay · non-live and makes zero OpenAI requests, so every judge receives the same repeatable experience without a key. The historical live receipt and the public replay are never presented as the same provenance.

Product design

The interface leads with the business decision rather than protocol details. A five-stage command center always shows the current stage, the required next action, what will change, what cannot change, and what remains uncertain.

A restartable seven-step tour explains the full journey. Source evidence, provenance, calculations, and hashes remain one interaction away through progressive disclosure instead of dominating the first viewport.

The complete workflow was exercised on desktop Chromium and Pixel 7, including keyboard-only navigation, focus restoration, touch targets, reduced motion, narrow layouts, serious/critical accessibility scans, reload recovery, duplicate submission, timeout, malformed response, and retry behavior.

How I built it

The product is a standalone Next.js and TypeScript application with workspace, plan, reconciliation, and health API boundaries. Shared strict Zod schemas reject unknown or malformed nested fields on both the browser and server sides. A second domain validator rejects invented IDs, incomplete evidence coverage, unauthorized actions, financial fields, numbers, currency, and journal instructions in model-authored content.

The deterministic engine owns the source fixtures, findings, action catalog, balanced journal templates, statement recalculation, readiness controls, and canonical evidence-pack digest. Content-addressed operations make retries idempotent, while a generated fixture trust manifest prevents a semantically false result from becoming trusted merely because its unkeyed hash was recomputed.

The application is containerized, runs as a non-root user, and is deployed through keyless GitHub Actions to Cloud Run behind Firebase Hosting.

How Codex changed the product

Codex was my primary build partner throughout Build Week—not a one-time code generator. Three reviews materially changed the product:

  1. Codex found that the acknowledgement flow treated different exception classes too similarly, so only genuinely uncertain items now require explicit acknowledgement.
  2. It found that the downloaded JSON added metadata after hashing, so the download now contains exactly the object whose digest was verified.
  3. It challenged browser-side trust and “human approval” wording. That led to shared strict browser/server schemas, server-owned reviewer provenance, a fixture trust manifest, and explicit separation between an unauthenticated demo assertion, browser-automation evidence, and future authenticated human approval.

Codex also helped build the adversarial evals, failure and recovery journeys, delivery gates, and evidence-bound release process.

Proof it works

The current deployed product SHA 11af1b2cdb0904b7139d0d6db95c361134177a45, Cloud Run revision kerdon-close-room-00015-xig, and its evidence-bound credential-free release passed:

  • 239 unit, domain, route, client, UI, and contract tests;
  • 18 offline adversarial model-contract evals;
  • 42 zero-retry desktop and Pixel 7 browser journeys;
  • 93.67% statement and 89.00% branch coverage;
  • production build and non-root container health;
  • candidate and hosted Firebase verification; and
  • cryptographic verification of the retained 6/6 historical GPT-5.6 evaluation receipt; the deployed release itself made zero OpenAI requests.

Exact release evidence is retained in CI run 29748204459 and the first-attempt successful delivery run 29748776386. The deployed image digest is sha256:dfaada6a929aae787635a2d6b37cb0335c290c59805e7062678ee9ba431495ff; rollback revision kerdon-close-room-00013-did remains available. Those revision, image, traffic, and rollback values are delivery-receipt-verified metadata parsed from the byte-bound committed product receipt; the separate public health gate verifies only exact release SHA and fixture-mode fields.

The public judge sandbox is available at upgradegr-kerdon-close-room.web.app.

Potential impact

The intended users are controllers, close managers, and accountable finance reviewers. Kerdon brings exception evidence, AI-assisted prioritization, reviewer decisions, deterministic recalculation, visible uncertainty, and exportable proof into one coherent workflow.

This synthetic submission does not claim measured production time savings. Its demonstrated value is a reusable authority pattern for consequential back-office work: AI can organize evidence and options while accountable people and deterministic systems retain control of what actually changes.

What was new during Build Week

Kerdon existed before Build Week with accounting-product context, document extraction, deterministic double-entry concepts, statements, validation, authentication, tenant isolation, and a dashboard.

This submission adds the isolated Close Room vertical slice: two committed synthetic periods, the findings and action engine, the GPT-5.6 planning boundary, reviewer-decision workflow, deterministic reconciliation and recalculation, evidence pack, judge UI and tour, adversarial evals, browser journeys, and a dedicated CI/CD path. It does not import, modify, deploy, or use data from the upstream Kerdon application.

What I learned

“Human in the loop” is not a sufficient trust boundary. A product must make clear what the model was allowed to see, what it was allowed to propose, what a click actually proves, and which system remains authoritative.

I also learned that provenance is part of interface design. Correct backend behavior is not enough if labels or restored browser state can imply stronger evidence than the system possesses.

What's next

The next production step would add authenticated multi-reviewer decisions, durable workflow storage, conflict handling, signed evidence packs, and carefully scoped read-only accounting connectors.

Those are intentionally not simulated here. The current experience uses only committed synthetic data; its public reviewer assertion is unauthenticated; and its SHA-256 digest proves content integrity, not identity, external notarization, or an audit opinion.

Built With

  • codex
  • docker
  • firebase-hosting
  • github-actions
  • google-cloud-run
  • gpt-5.6
  • next.js
  • openai-responses-api
  • playwright
  • react
  • typescript
  • vitest
  • workload-identity-federation
  • zod
Share this project:

Updates

Submission history