Continuity Core Resurrection

Purpose

Reconstruct a dormant, renamed, multi-provider project from concept identity, events, checkpoints, bindings, and receipts.

Mechanism

The demo starts with scattered sources and conflicting labels. It resolves aliases, verifies bindings, separates proposals from decisions, identifies stale implementation, and produces a Resurrection Surface.

Deterministic fixture

One project with three names, two repos, four chats, one accepted spec, one model proposal misremembered as a decision, and a stale deployment.

The fixture must live in content/demos/d17-continuity-resurrection/fixture.json, validate before the demo renders, and be resettable without a network call. A future live adapter may be added behind a visibly separate mode.

Required controls

• Scan sources
• Resolve alias
• Open event lineage
• Promote/reject statement
• Verify repo binding
• Generate checkpoint
• Simulate dormancy
• Resurrect
• Compare transcript-only recovery

Visible states

• FRAGMENTED
• IDENTITY_RESOLVED
• CONFLICT
• CHECKPOINTED
• DORMANT
• RESURRECTED
• UNKNOWN

Every state must have text, iconography, and a non-color-only distinction. State transitions are logged in an in-memory demo receipt visible in the inspector.

Core assertions

1. Assistant proposal is not returned as founder decision.
2. Rename preserves concept lineage.
3. Stale binding remains visible.
4. Resurrection lists accepted, blocked, unknown, and next action separately.

Layout

The page contains:

1. a concise mechanism explanation;
2. the interactive stage;
3. a state and evidence inspector;
4. a reset control;
5. a “what this proves / what it does not prove” panel;
6. links to the related paper and benchmark contract.

On narrow screens the inspector becomes a bottom sheet. The stage must remain usable at 360 CSS pixels.

Accessibility

• All operations are keyboard reachable.
• Pointer gestures have button or keyboard equivalents.
• Animated transitions honor prefers-reduced-motion.
• Focus remains visible and returns predictably after sheets close.
• Diagrams expose concise text alternatives.
• Status is announced through a polite live region only when the user initiates the transition.

Instrumentation

Record locally:

demo_id
fixture_version
action
prior_state
result_state
validation_result
timestamp_relative

Do not send telemetry. Provide “Export demo trace” as JSON for debugging and reproducibility.

Automated tests

• fixture schema validation;
• deterministic reset;
• every required control transition;
• every assertion above;
• invalid and stale fixture handling;
• keyboard path;
• 360 px and 1440 px screenshots;
• zero critical console errors;
• no request to a paid API in default mode.

Publication boundary

The demo uses a fixture corpus. Account-scale recovery accuracy requires the benchmark.

The interface must never convert illustrative values into a benchmark claim. A measured result appears only when linked to a versioned run receipt.