# Fixed completion plan for the Odexa v1.2 candidate

18 September 2026. Updated after the completed integrated review, four technical corrections and current regression/installation evidence. This plan preserves the [ten original release gates](RELEASE-CANDIDATE-GATES.md); it does not declare a narrower release complete. The sixth snapshot remains the immutable downloadable baseline. Earlier milestone counts below are historical, not the current aggregate. Current gate dispositions and exact results are in [the release audit](RELEASE-AUDIT.md). Website copy at commit `c782b5f` is separately published and verified; it does not publish this development source.

## What the planning audit established

This section records the pre-M2 audit. The paid-archive, provider-handover and observation-coverage gaps below are now addressed under M2–M4; this historical inventory remains as the evidence that determined the work, not a current missing-work list.

All 292 inventoried sixth-snapshot source files matched their recorded SHA-256 values before this documentation update. The saved complete run reports 553 Python tests, 91 Node tests and 189 structural cases across eleven schemas. The source inspection checked the current service/payment/archive dispatch, install entry point, managed-agent boundaries, named integration tests and accumulated review dispositions. No runtime change has been made in this audit.

The missing work is concrete:

- `profiles/paid_evidence.py` does not exist. The non-importable prototype at `research/incomplete/paid_evidence.py.txt` still applies free-only lifecycle assumptions and lacks complete payer/audit replay. It cannot be promoted by renaming it.
- Current archive dispatch accepts ordinary/storage/asset **free** profiles. Actual paid agreements and selected paid storage already work, but neither has a complete supported archive.
- `pyproject.toml` installs `odexa-reference = odexa_ref.server:main`, the draft-2 entry point. The new draft-3 service is exercised through programmatic adapters and test fixtures; there is no current installed quickstart.
- The Node free/storage wire clients exercise real direct and delegated exchanges. They do not verify the complete native asset graph or perform the full paid payer/verifier flow independently.
- History, payment-verifier rotation and retired/compromised signature tests exist. A complete operational change from one provider to another, with new credentials and preserved original evidence/use terms, is not demonstrated.
- Measurement keeps observed delivery and client assertions separate, and storage accounting identifies known gaps. An origin-wide declaration of observation boundaries and their denominators is missing.
- Component documentation is extensive but not a consolidated normative edition. Some earlier status prose still describes subsequently implemented components as missing. Historical drafts and review reports need explicit precedence.
- Review agents are terminal at an account usage limit. Their earlier findings remain useful; they have not reviewed the complete sixth integration. Root's testing does not replace the requested completed team review.

## Historical gate disposition at the planning checkpoint

“Component evidence present” means the named implementation has relevant executed evidence. It is not an independent completion percentage or final candidate sign-off.

| Original gate | Audit finding | Completion milestone |
| --- | --- | --- |
| One authoritative specification | M1 working index now centralises modules, versions and dependencies; final consistency review remains | M1, finalised in M6 |
| Executable contracts | Component/schema evidence, paid archive and transition fixtures, and observation coverage contract/corpus present | M2–M4 evidenced; integrated check M6 |
| Direct free operation | Actual direct TLS, independent Node, retained receipts/retries/revocation and managed storage demonstrated; installed current quickstart now evidenced | M5 evidenced; M6 review |
| Delegated operation | Actual delegated exchange and two-provider handover demonstrated; installed configuration is evidenced; complete independent native-asset graph now evidenced | M3–M5 evidenced; M6 review |
| Optional payment orchestration | Quote/mandate/verified state/access separation, actual TLS and paid archive/replay demonstrated; independent paid client coverage now evidenced; native asset graph is separately evidenced | M2/M5 evidenced; M6 review |
| Traceability and measurement | Native asset/catalog/archives, source-qualified reports and declared coverage/known denominators demonstrated; independent native graph client now evidenced | M4–M5 evidenced; M6 review |
| Lifecycle and portability | Free/paid archives, live two-provider handover, original terms/evidence, fresh credentials and key rotation demonstrated | M2–M3 evidenced; final review M6 |
| Conformance and independent review | Requirement map and earlier four-perspective findings exist; current integrated review incomplete | M1, M5, M6 |
| Implementer documentation | Licences/component guides exist; handover guide now present; current installation/security guidance present; final normative consolidation incomplete | M1, M3, M5, M6 |
| Website alignment | Existing publication records support the agreed roles; new candidate not published | M6 release plan; website operational follow-ups below |

## Ordered milestones and stopping conditions

Each milestone closes the stated existing requirement. A discovered defect is corrected within that requirement; it does not silently create another product or capability. The sequence is fixed unless evidence establishes a dependency.

### M1 — Establish one specification and conformance index

**Working index established in this checkpoint:** [SPECIFICATION.md](../SPECIFICATION.md) provides the normative document/schema inventory, capability classes and dependencies, current profile/version table, conflict precedence, and compatibility rules for historical material. It covers discovery/static policy, direct/delegated operation, free/paid agreements, assets, source-qualified evidence, duties and lifecycle. Original exact wire identities remain intact; draft-2 is not relabelled as draft-3.

Finish when an implementer can locate the authoritative contract for each original requirement and distinguish working code, normative requirements still awaiting implementation, and historical examples without reading a chronological work log. Final field-level consistency is checked in M6 after the remaining interfaces are implemented. Existing prose is reused and corrected rather than independently rewritten into contradictory specifications.

### M2 — Complete paid portable evidence

**Implementation and automated evidence complete for the four bounded reference profiles.** [Paid portability](PAID-PORTABILITY.md) now specifies the working interfaces, independent payer trust, exact audit replay, storage/asset dependencies and assurance limits. The final whole Python run passes 571 tests; the combined schema corpus passes 245 cases across 15 schemas. Independent Node paid/graph coverage was subsequently evidenced in M5; final team review remains M6. This component completion does not declare those separate milestones complete.

Deliver explicit ordinary/storage paid archive profiles and native-asset variants, using the existing closed inventory and inert archive infrastructure. Preserve original quote, assent, receipt, independently pinned payer key/mandate, exact provider-signed checks, historical authority and ordered audit/state evidence. Recompute pending/failed/confirmed/reversed and expired/revoked access without inventing settlement or restoring permission.

Finish when actual paid TLS flows export and import independently, including pending without a mandate, failed-to-confirmed recovery, reversal, late confirmation, exact retries and restart. Authorised-exporter tampering must fail for omitted/reordered/substituted audit material, wrong payer/verifier, changed amounts, incomplete asset/storage dependencies, missing independent pins and terminal access resurrection. Imports contain no secrets or live access grants. New schemas/fixtures cover every new wire envelope. Paid and free entry points stay explicitly selected.

Use the current shared archive code; the interrupted prototype is a design reference, not trusted implementation. Do not build a debit processor, financial account UI or new settlement rail.

### M3 — Demonstrate provider and key transitions

**Procedure and automated evidence complete for fresh-agreement handover.** [Provider handover](PROVIDER-HANDOVER.md) specifies the origin-controlled steps using existing closed messages. Six real origin/two-provider TLS tests and three focused historical-key checks pass. They cover free/paid fresh assent, scoped credentials, preserved inert archives and accepted terms, limited storage collector authority before full withdrawal, both origin/successor outages, durable rollback denial and new-key signing. The runtime and wire schemas did not change; current installed operator tooling remains M5 and integrated review M6. No transparent rights-transfer feature is claimed or substituted for the supported fresh-agreement procedure.

Deliver the origin-controlled handover contract and reproducible transition flow: retain original signed evidence and independent history; explicitly appoint the successor; provision separate scoped credentials/keys; stop future authority of the withdrawn provider; and require the documented new or transferred agreement procedure for new access. Historical accepted use/retention terms remain unchanged.

Finish with a real two-provider transition and fresh credential tests. Old credentials cannot operate the new provider, withdrawn authority cannot authorise new operations, outages/rollback do not create fallback permission, and historical archives remain separately qualified. Key retirement and known compromise have different outcomes. No copied database or archive silently becomes a transferable bearer grant. A supported fresh-agreement handover must say exactly how it handles existing paid rights; it must not imply transparent rights transfer where none is specified.

### M4 — Finish measurement coverage and duty boundaries

**Reference module, contract and focused evidence complete.** [Observation coverage](OBSERVATION-COVERAGE.md) defines the separate `observation_coverage_v1` publication profile, policy-bound verified HTTPS acquisition/history and a reducer over authenticated intakes plus trusted expectations. Twenty-two new methods and 23 structural cases pass; the 83-method regression slice includes the new tests and existing storage/free/gateway contracts. Four new TLS cases cover standalone publication, actual collector evidence, report-only participation and failed acquisition. Declared scope, unknown gaps, overlapping boundaries, wrong profile/agreement, conflict order, pending/missing/late reports and storage/action separation stay explicit. There is no inferred whole-origin traffic denominator. Installed current operator tooling remains M5 and integrated review M6.

Deliver an origin-authorised observation-boundary/coverage contract and reducer/reporting guide. Declare which gateway, collector or participating agent can observe which resource/action/interval; retain unknown/missing boundaries. Separate delivery attempts, completed local writes, continuing custody, client claims and downstream inference. Cover static/manifest-only publication and report-only participation without pretending either provides protected delivery or complete traffic visibility.

Finish with deterministic examples and adversarial cases for partial coverage, overlapping boundaries, absent expected reports, unresolved admissions, late data and profile mismatches. Every percentage has an explicit known denominator. Unsupported actions/duties are declined; no reference client is required to implement an LLM trainer or observe undisclosed copies. Existing supported retention, attribution, reporting and continuing-storage duties must remain executable and clearly selected.

### M5 — Ship a reproducible current implementer path and independent client

**M5 implementation and focused evidence complete; final release validation/review remains M6.** The [current quickstart](CURRENT-QUICKSTART.md) provides the installed direct/delegated free and optional synthetic fixed-quote path, with 57 clean-install checks and eight adapter tests. The [independent paid client](INDEPENDENT-PAID-CLIENT.md) supplies 49 native semantic cases and eight wire methods. The [independent native asset client](INDEPENDENT-ASSET-CLIENT.md) now covers complete direct/delegated and cross-origin graphs, independently obtained authority/history, original publication bytes, representation comparison, persistent immutable pins and hostile cases. All 191 standalone Node tests and the 21-method wire regression pass, including nine new asset methods executing 22 fresh client processes. Original exit conditions below remain intact and are evidenced by these component records. M6 has now run the complete current-source and clean-install checks and prepared the release audit; integrated review and final publication operations remain. Security-report intake must be verified before candidate publication; no monitored inbox is claimed.

Deliver an installed draft-3 entry point and self-contained configuration/quickstart for direct free operation, delegated free operation and optional fixed-quote verification. Keep implementation code out of test-only fixtures. Include static publication, authority/key provisioning, restart, reporting, archive verification and migration instructions. Provide the runtime/dependency and security-reporting inventory.

Finish by installing the built package into a fresh environment and following the documented commands without importing `tests/`. The free path uses no third-party account or payment configuration. Extend the separate native Node client to exercise paid flow and native asset graph semantics against the Python service; compare genuine valid/hostile wire cases, not only JSON structure. Retain working independent free/storage checks. A scripted CLI is sufficient; an interactive setup wizard is not an additional release requirement.

### M6 — Review the integrated candidate and prepare publication

**Integrated review and technical corrections complete; release operations remain open.** [The audit](RELEASE-AUDIT.md) records 644 Python methods, 206 Node tests, unchanged schema/fixture evidence and 57 fresh installed-flow checks. The specification has 47 numbered requirements and 180 explicit evidence links. All four baseline reviews and technical follow-ups are recorded in [the integrated dispositions](../reviews/INTEGRATED-DISPOSITIONS.md). Verified private security intake, final frozen artifact and candidate publication remain outstanding. Passing suites must not be repeated without a new source change or unresolved failure that justifies it.

Deliver the final normative edition, per-capability MUST-to-evidence map, migration/changelog/licensing package and proposed website release content. Complete the CTO, Chief Data Engineer, AI Research and Chief Product Officer assessments against the exact integrated artifact and record every material finding/disposition. Internal review roles must not be presented as human certification. Review unavailability cannot be replaced with invented approval.

Finish after the relevant complete Python/Node/schema suite, clean installation/quickstart, archive integrity and documentation/link checks pass for the final source; material findings are resolved; and each original gate has direct evidence. Freeze one candidate artifact with a version that reflects its actual status. Only then update the versioned Odexa documentation/release links. Preserve the Foundation/commercial provider positioning and previous immutable release. Website preview/rollback and live checks remain explicit publication steps, not implied by local tests.

## Website operational follow-ups

These remain in the wider website brief and are not reasons to rebuild protocol components:

1. Complete a controlled live consent/page-view/GA4-delivery check for all three sites using the existing Google setup. Inspect whether any earlier browser permission requirement still applies; do not repeatedly seek permission already implied by the user's authorised setup.
2. Check the existing Gmail destination-verification state. Activate `hello@odexa.org` forwarding only after verification and validate delivery; avoid repeated unsolicited resend attempts. Inbound forwarding alone does not provide branded outbound replies.
3. Keep the active Foundation's wider fair/open-web mission, council-forming status, research/position-paper labelling and council application contact accurate. Keep dark .org/light .io shared Odexa styling and commercial provider's existing design.
4. Maintain the two approved GitHub/CMS repository connections and current hosting. Recheck only changed content/deployment paths at candidate publication. The existing CMS save/build path is already evidenced; a new CMS or rebuild is not required.

The original earlier foundation research has not been supplied as source material. Continue labelling the current paper as a position paper/research agenda; do not present it as the user's historical research or fabricate results. Do not claim unsupported council application volume or established independent governance.

## Execution and credit controls

- One bounded implementation item per checkpoint, with the exact remaining work reported. No new feature stream without a requirement or concrete defect that makes it necessary.
- Use existing modules and evidence. Run focused checks after relevant changes; run the complete suite for the final integrated milestone or when changed shared contracts justify it. Do not rerun passing suites or regenerate immutable ZIP snapshots merely to produce a progress update.
- Preserve r6 as the current tested download. Record working changes and focused results until a new coherent milestone warrants packaging.
- Do not retry quota-stopped reviewers repeatedly or consume/reset credits without explicit authorisation. Use independent reviews when available, with a bounded artifact and question.
- No further credit/dollar limit has yet been specified. The budget question is pending; this document does not invent an approved cap, a reliable cost estimate or a completion percentage. Report scope and evidence at each checkpoint so the owner can stop or set a cap.

M1–M5 implementation evidence is retained. M6 now has a consolidated specification, completed four-role review, resolved findings and complete corrected-source/installation validation. Verified private security intake, final artifact freeze and publication/live checks remain. The original ten release gates are not yet all satisfied.