Singular delivery roadmap

As a KERI integrator, I want to register an identity and permanently terminate its original registry entry, while later Singular capabilities leave that instance's contract unchanged. As a future registry consumer, I want the additional edges and their existing work to remain available for a later release.

Scope settled 8 October; compatibility sequencing updated 12 October 2026. These are delivery boundaries, not completion claims or permission to start new workers. Existing owners, pauses, candidate history and evidence remain intact.

Milestone outcomes

Milestone	Outcome	Required registry edges	Existing delivery
Permanent registry for KERI	Register, maintain application data and permanently terminate on the original instance	insertActive, updateTerminal	Demo 1, open-datum application, permanent preservation and bounded contract
Shareable script family	One published copy of the request validator, the witness policies and the application script serves every registry; participants discover the scripts they need from the chain and publish only what is missing (Demo 2)	No new registry edge; the script family changes hash once	Shareable caches, Demo 2; not needed for KERI, so after Demo 1 and before the extensions
Native/browser compatibility	Swap CIP-30/native wallets and runtime backends over shared portable packages; preserve submission/recovery evidence	Existing two-edge contract only	Interface design, epic #584; priority at KERI handoff, parallel with script sharing
Registry extensions	Attest termination, reserve and activate keys, remove reservations or active entries	witnessTerminal, insertAbsent, updateActive, deleteAbsent, deleteActive	Retained registry work; explicit later delivery, not first-milestone gates
Programmable naming and escrow	Manage application-bound names and pay the first non-retired name in an ordered list	The edges its accepted consumer model requires, including terminal attestation for escrow	Programmable naming, Name Your Address
Tooling, performance and maintainability	Reuse checked history, rebuild node-backed views, drain queues and maintain focused modules	No new registry edge required by this milestone	Existing follower/folder/naming tooling, persistent indexing, optional local-indexer readback and module refactor
Assurance refinements	Extend coverage and compiled-program assurance across releases	Scope follows the release being claimed	Existing deferred assurance; it does not waive the first release's required boundary checks

After the permanent two-edge registry is ready for the KERI handoff, native/browser compatibility is the priority. It can run in parallel with the shareable script family (M1.5); neither compatibility nor Cardano KERI work waits for script sharing. M2 remains the five missing edges and waits for completed compatibility as well as its existing prerequisites. Naming/escrow follows its required edges. GitHub milestone numbers are stable identifiers: M2 is URL number 5, M1.5 is number 6, and compatibility is number 7; no milestone was renumbered.

flowchart TD
  A[Two-edge registry and KERI handoff readiness] --> K[Cardano KERI work]
  A --> W[Priority: native/browser compatibility]
  A --> S[M1.5: shareable script family]
  W --> B[M2: five missing registry edges]
  S --> B
  B --> C[Naming and escrow]

The arrows express delivery prerequisites, not state migration. Each deployed instance has its own contract. The later 8 October ruling abandoned earlier-release registries at the M1 identity change; this plan does not restore the withdrawn recognition requirement. Current constitution and recorded rulings govern recognition.

The open-datum application stays

Registration delivers the active token, payload and protected deposit to the application. A controller-authorized payload update spends and recreates the application output while preserving its token, control fields and deposit; it requires no registry edge. Termination burns that token through updateTerminal and releases the deposit. These duties are already the application contract, not new edge work.

KERI close/reopen is likewise application-level. The operator reports that KERI's Lean model does not consume terminal witnesses. That settles the consumer scope used here; it is not a fresh independent model execution or actual KERI integration receipt.

Historical 8 October plan: preserve first, then restrict

The bounded-contract epic has three serial children:

1. Preserve the broader work permanently: retain exact Lean/on-chain source, relevant candidates and evidence on a remote branch, proposed name preserve/m2-registry-extensions, with a recoverable manifest and cleanup exclusion. This branch is required work, not yet claimed created.
2. Deliver the runnable restricted contract: update the explicit Lean boundary first, then align compiled admission, builders, codecs and identities while reusing Demo 1.
3. Verify the packaged boundary: reproduce allowed behavior and intended refusals for all five deferred edges, including independent transactions, alternate paths and mixed batches.

At that planning baseline, the broader model admitted witnessTerminal without an application approval. Restricting the application's approval policy alone therefore does not prove the required two-edge boundary. Preserving broader source or hiding a CLI command does not enforce the deployed contract either.

What remains open

Two rulings of 8 October reshape the first milestone's command line and request format. The Singular executable is the registry only (create, fold, reject, reclaim, inspect); the open datum becomes its own executable built on the Singular library, the way cardano-keri's ckeri will be (#528). Every request carries a tag minted by Singular's request policy, untagged outputs at the request address are spendable by anyone, and every tagged request has an exit (#529). The 8 October sweep placed every open issue in a milestone; the conformance-bible epic and its children are assurance work, not milestone gates.

The first milestone still needs its bounded artifact, applicable request exits/refunds, independent-actor Demo 1 evidence, permanent contract recognition and KERI consumer correspondence. The later 8 October ruling withdrew #480 earlier-deployment recognition; the current constitution records the identity-change policy.

Consumer conformance and demonstrated KERI integration are distinct. The later 8 October ruling settled that KERI integration is not an additional M1 closing requirement; the open-datum Demo 1 and protected-rejection conditions remain. The new priority does not declare M1 complete.

The extension milestone has retained tickets for terminal attestation, custody wire, reservation command and activation. The two deletion delivery slices remain explicitly unticketed, owned by the project desk for later decomposition. Their presence in a model or source tree is not delivery evidence.

The earlier delivery register preserves its original evidence and gaps; it is not the revised milestone completion checklist. The Demo 1 page retains the concrete demonstration requirements. No conformance row changed state, no issue was closed and no paused lane was resumed by this restructuring.

Native/browser compatibility priority — 12 October 2026

Milestone 7 / epic #584 implements wallet/witness, storage, runtime and evidence contracts and separates portable packages from native/browser adapters. CIP-30 is the browser wallet boundary; the existing ledger-provider interface is retained. The design records exact surveyed revisions, interface signatures, migration and acceptance criteria.

The operator wants this work prioritized when switching to Cardano KERI, which can happen before script sharing. It may run alongside M1.5 with coordination for shared builder/release files. M2 still owns witnessTerminal, insertAbsent, updateActive, deleteAbsent and deleteActive, and cannot introduce them before compatibility is accepted. The M2 epic and existing edge tickets carry native blocking links; future deletion tickets inherit the same prerequisite.

No runtime implementation, browser acceptance, staff launch or paused-lane release is claimed by publication. Existing #490 vault and #545 effect ownership retain their scope.