Codex
Reads intent, researches evidence and prepares options.
Finite / public build record
Flexible plans. Firm boundaries.
The engineering behind Finite: an agent can propose a different plan, but it cannot approve its own changes. Here is how that boundary works, with the source and tests to inspect.
Back to the productEngineering / Codex for judgment, code for control
Codex proposes the change. Finite protects the plan.
Codex handles language and research. Finite's code handles arithmetic, constraints, persistence and approval.
7 native WebMCP toolsPermanent registry · bounded manifests
Finite kernel
Checks constraints, binds revisions and rejects stale or unapproved writes.
Atomic repositoryOptimistic concurrency · exact retry
D1
Commits the plan head, revision, receipt, events and evidence in one transaction.
One accepted truth
The current plan is an immutable revision with a replayable history.
Rules stay code
Conservation rules, locks and relationships run in code.
Research stays evidence
Prices, availability and other observations are stored with provenance and treated as untrusted.
Authority stays human
WebMCP cannot create authority. Every accepted mutation consumes one exact server challenge bound to its target, content and revision.
Writes fail closed
A failed write restores state and idempotency so the same operation can be retried.
Every change leaves proof
Each operation records input, result and plan-context hashes.
Current scopeFinite can model, compare and revise a plan. It does not yet change bookings, make purchases, pay suppliers or report that another system acted.
Build log / recorded milestones
What has been built and tested.
The latest recorded milestones, followed by the earlier build history. Test totals belong to their dated release, not every subsequent change.
View full size ↗
One concrete change
Show the trade-offs, not every combination.
Eighteen passing combinations would be a lot to compare. The Paris example groups them into five distinct directions, so the person can choose what to protect. The search is bounded by the model's permitted changes, not every possible real-world solution.
Read the search tests ↗ · Inspect the full example and its limits
- Build 18
The result count now fits the situation.
Finite returns every meaningfully different workable direction it finds instead of forcing every plan into three choices. The public Spotlight example checks 26 combinations, accepts 18, rejects eight and returns five distinct directions; another plan can honestly return one.
- Build 17
The source is public under the MIT licence.
The full repository, acceptance records and reproducible release instructions are published with continuous verification. The public tree independently passes 373 of 373 tests, type checks, production builds and the submission gate.
- Build 16
Your chosen starting point takes priority.
A remembered demo must not override a deliberate fresh start or collaboration link. Release v242 corrected those entry paths alongside invalid money and date handling. Dialogs also retain failed edits and restore keyboard focus, so an error does not make the person start again.
Earlier milestones Builds 03–15 · 26 Aug to 1 Sep 2026
- Build 15
The live walkthrough survives reload and replays safely.
A browser-local walkthrough resumes across reload, the Site-selected entry is canonical, pre-connection status is truthful and a replayed apply changes nothing. Console, 1280 px and 390 px overflow checks are clean on production.
- Build 14
Sixteen complete user journeys run end to end.
Sixteen sequential real-interface journeys were run against the candidate, the defects they exposed were repaired and the full regression gate passed before release.
- Build 13
Guarded activation and a second plan family on production.
Starting a new plan consumes an independently stored human-action challenge, the visible move into Managing stays under half a second, and a renovation plan activates with its own cross-family semantics.
- Build 12
One whole journey, from arrival to a shared finished plan.
Arrival, planning, managing, completion and sharing run as one continuous interface. Three real Chrome stress scenarios passed and temporary test state was reversed.
- Build 11
Accounts and custom plans survive the empty-browser test.
Browser state is tenant-scoped, new accounts begin empty and D1 stores the complete hash-validated compiler definition needed to reconstruct a custom adaptive surface on another device.
- Build 10
Every accepted change crosses the same authority boundary.
Options, corrections, preferences, lifecycle, group decisions, external-action truth and plan activation all require an exact server challenge. Arrival closure also proves the current durable plan head.
- Build 09
The native kitchen survived full-family pressure.
Travel, renovation and event completed ordinary changes, late shocks, bounded recovery and honest conclusions. Seven permanent browser tools now open only the bounded semantic manifest needed for the current route.
- Build 08
A fresh Codex task receives one next action.
The entry packet checks arrival work against accepted-plan work and returns up to three routes grounded in current state. Suggestions, research, validated options and human decisions are stored as different states.
- Build 07
Codex can start from a short handoff.
The handoff points a fresh task to
finite_enter_kitchen. Finite returns the current arrival, accepted plan, authority state and next route. Plan contents stay in the product. - Build 06
Site and Codex work can resume after a delay.
Human input is append-only. Checkpoints, version checks and staged clarification prevent an older session from overwriting later plan state.
- Build 05
Travel, renovation and event compile to different surfaces.
Travel uses a calendar, renovation uses a phase lane and event uses a run of show. Each surface has its own measures, language, entities and actions. State and approval rules remain shared.
- Build 04
Plan state commits atomically for each tenant.
D1 commits the plan head, revision, receipt, domain event and evidence in one transaction. ChatGPT identity derives the tenant. Finite does not store the credential.
- Build 03
WebMCP cannot create human approval.
Codex can orient, research, compare and stage. Approval creators sit outside WebMCP. Every consequential command binds to one candidate and revision.
Reproduce the recorded release ↗ · Inspect repository verification ↗
Roadmap / what needs to work next
Reliable first. Portable next.
Make starting and returning dependable, then make Finite easier to run independently. Booking and payment integrations come later: approving a plan must never imply permission to spend.
Start clearly. Resume safely.
- A first-time user can connect Codex without prior context
- Returning to a plan opens the right work and current revision
- Public examples and their evidence match what the product actually checks
Run Finite independently.
- Standard OIDC sign-in and a guided self-hosted installer
- Export, migration and first-run setup
- Recurring-period and milestone planning experiments, tested before wider release
Connect planning to action.
- Booking, supplier and calendar integrations
- Separate permission for each external action
- A receipt that confirms success or clearly records refusal
Finite / product
The engineering exists to protect the experience.
Return to the product page to see the same planning engine adapt across travel, renovation, events and your own outcome, or open the live product and run the walkthrough yourself.