Singular demos and the Cardano KERI handoff

Scope update, 8 October 2026: Demo 1 supplies the first milestone's two registry edges. Its open-datum updates remain application-only. The five additional registry edges now belong to the next registry milestone, and naming/escrow follows later. The current roadmap supersedes earlier wording that counted those wider outcomes as first-milestone gates. Existing Demo 1 evidence obligations remain; epic #507 covers permanent preservation and the enforced two-edge boundary.

Reconciled 7 October 2026. Demo 1 is still in progress. 8 October is a review target, not a delivery promise. Main has green checks after the 6 October repairs and CI restructuring; required actor, onboarding and recovery outcomes remain open. The latest published release is v0.9.0; #354 proposes v0.10.0.

See the M1 stories and dependency chart, Demo 1 acceptance, 8 October review card and demo timeline. This page separates the required demonstration from the evidence already obtained.

The rehearsal improvements, in merge order, each with its tickets and what the demo gains, are on Demo 1 checkpoints.

What Alice and Bob must demonstrate

Alice and Bob start independently. Each opens a separate terminal with their own home and an empty registry directory. They start from the registry's public page, which identifies its state token and release, and use Koios. Neither receives the creator's files, a copied registry configuration, the other actor's directory or a private datum envelope. The page is generated from chain data and can be rebuilt by another participant. This is the revised 6 October acceptance in #301, with onboarding in #437.

Alice books; Bob can fold. The request must contain the public data needed to deliver its datum, so Bob can fold Alice's insertion without asking her for a file. If Alice and Bob book together, one fold settles all pending foldable requests and binds each payout to its owner. Expired requests are identified separately. These outcomes are being implemented in #419 and #396.

Alice controls her application data and deposit. The application has a protected envelope with arbitrary PlutusData payload. The controller key, registry/token/key identity and protected deposit are control fields. Alice can update the payload with her Cardano key; the token and deposit stay at the application contract. Authorized termination burns the token, commits Terminal for the same registry/key and releases the original deposit. Unauthorized updates, early deposit withdrawal, duplication and resurrection must be refused at their intended boundaries, with accepting controls. A timeout or setup failure is not a validator refusal. Application contract #310.

Both can see the evidence and its limits. Commands must expose the actual protocol activity and distinguish client, provider and ledger outcomes; #416 owns the live narration. Koios facts are explicitly Unverified, and sessions Unbound. Reconstructing a trie and matching its root to provider data checks that computation; it does not independently verify the ledger. The broader delivery requirement for two named independent public indexers remains open under #300; the Koios-only operating path does not silently satisfy or remove it.

What exists today

Capability	Evidence on 7 October	Remaining boundary
Ordinary CLI and application foundations	Model, scripts, builders and CLI slices landed through #312/#316/#317/#319.	The revised independent-actor product journey remains unaccepted.
Public-history reconstruction and Koios routing	#391, #392, #402, #410 and #411 merged. The fold-control regression was repaired by #440; attach-window repair #434 also merged.	Matching provider roots is not ledger verification or proof of complete independent operation.
Separate actors, public datum and joining	#433 and #421 remain drafts; #437 and #396 remain active work.	The public request datum, creator-file-free join and concurrent fold are not delivered together.
Provider cleanup and read evidence	#460 is unmerged at 6de04fb9, with three failed Registry checks. Later local repair checks have narrower source/evidence bounds.	Exact published-head CI and the original complete provider requirements remain open; #413 receipt evidence and #361 refund correspondence are not closed.
Extracted archive and existing-registry demonstration checks	Passed on main 25c79a01, alongside public-indexer fixture readback and conformance.	Development-network and fixture results do not establish the revised authorized preprod recording or two live public indexers.

Green CI and the remaining evidence gaps

Main 25c79a01 has successful CI, Registry and Conformance runs. On 6 October the long jobs were removed and then partly restored as parallel jobs. Archive/readback, existing-registry refusals, conformance parts and E2E parts now have successful results; selection and receipt checks guard against a part passing without executing its intended cases.

The coverage limits remain visible:

• Inspection with missing evidence: #441 remains open. The old control removes local proof files that inspection no longer uses. Its backend reports no applicable witness and the clause stays uncovered. The proposed replacement withholds public history and requires refusal without a leaf; its description ruling and actual execution are not claimed complete. The ordinary refusal-controls suite is not currently a scheduled main job.
• Recovery: accepting, lost-acknowledgement and killed-process parts run in CI. Cross-wallet folds, never-sent, whole-journal, rollback and the trie clause remain unmet or unverified. #451 tracks another wallet's fold failing before its intended hold point; the exact cause must not be assumed. #449 owns the complete redesign with offline failure modes and bounded parallel edge jobs.
• Infrastructure: #442 records interrupted historical runs. Those interruptions are separate from completed product failures, and successful later runs do not rewrite the old evidence.
• Creation funding: #406 records creation booting before later reference-script funding fails. The permanent-registry funding risk remains open.

Path to the rehearsal

1. Complete public request data, state-token joining, batch folding and the separate-actor controls; finish the applicable provider and narration work.
2. Resolve the required refusal/recovery evidence gaps and integrate reviewed candidates with exact-head CI. Preserve model/consumer holds and uncovered rows.
3. Bind one coordinated breaking release to the model, scripts, executable archive and public page. A published v0.9.0 or proposed v0.10.0 is not automatically that artifact.
4. Obtain the concrete authorization for a new preprod registry required by the changed encoding and reference-script placement. Account for permanent registry funding, application deposits, request deposits, tips and fees separately.
5. Reuse that registry for the two-terminal rehearsal with fresh keys, retain actual transactions and partial outcomes, and record the demonstration.

The registry cannot be destroyed or migrated under the current semantics. The new-registry checkpoint is not permission to create one per take. Terminating an application entry does not return permanent registry funding. Replay caching #493 and persistent indexing #377 are explicitly after Demo 1.

Wider requirements and review targets

Demo 1 does not complete M1, registry-mode #154, Name Your Address #141 or KERI integration. Terminal witnesses #158, Absent custody #178, activation #179, naming #174, missed-window retirement #130 and ordered-name escrow #152 retain their own acceptance. E209/#233 remains paused; its conformance and transaction-size gaps are not waived by the demo work. The large-module refactor #432 is planned, with nine children and no implementation claimed.

Review target	Demonstration sought	Boundary
22 Oct 2026 (re-dated on 8 Oct, review card)	Demo 1: independent participants, protected payload/deposit and permanent termination	Review target set from the journeys the demo cannot do without: safe creation, independent join, one fold for several bookings, restored references. No readiness guarantee; release, registry authorization and connected evidence still required.
Demo 2, undated	Shared script references: one participant publishes a missing script, the others discover and reuse it from the chain (#473, milestone M1.5)	After Demo 1; dated when Demo 1 has landed.
30 Oct naming stretch	Withdrawn on 8 Oct: naming has no owner and no date; its old journeys are deleted and it is re-cut on registry mode in milestone 3.	No naming review in October.
November	No presentations during the operator's holiday	Calendar entry grants no delivery or staffing authority.

The previous v1.0.0 Demo 1 and v2.0.0 naming labels remain planning targets, not published artifacts. No new delivery date is inferred from this update.

The joined keripy/ckeri/Singular journey and Cardano KERI mapping #324 are downstream outcomes; a dependency pin is not behavioral integration acceptance. See the KERI demo path and correspondence register #435.

Historical evidence

The naming registry's v0.6.1 preprod record and v0.7.0 foundation release remain evidence for their original revisions. Neither establishes the revised Demo 1 or Bob's escrow journey. Older failed or partial rehearsals remain evidence; later green checks do not erase them.