# Opening video: from registration to one verified history

**Duration:** 170 seconds (2:50). **Composition:** 1920 × 1080, 16:9, 30 fps. **Current audio:** silent; narration follows this content pass. **Preview:** seconds 0–54, ending on Alice's pending request at A. This shot list accompanies the [editable composition](composition.js) and [35 timed caption cues](opening.vtt). The earlier ivory version (repository archive) remains preserved.

The sharpening pass keeps the same nine shot boundaries and worked example. It makes the comparison targets, order, and before/after states visible in objects before narration is added. Caption windows are unchanged, contiguous through 170 seconds, and at least three seconds long.

The example follows the visualization handoff (repository document), shared substrate model (repository document), open decisions (repository document), and [deterministic walkthrough](substrate-walkthrough.html). Heights, positions, identifiers and commitments are illustrative. All required inputs are assumed eligible and available. Execution uses the current working proposal; the film performs no actual cryptography or SuperNova proving.

## Visual continuity

Keep the engineering blueprint style: dark navy, quiet static grid, fine drawing lines, cut-corner cards, hexagonal registrar badges and pale lettering. A is cyan, B coral, C violet; the gold Bitcoin band separates public commitments from off-chain storage. A remains left, B center, C right in network views.

Use recognizable objects throughout:

- **Public identity:** each mined registration receipt keeps its identity label, such as **Identity A** inside **Block 1**.
- **Signed operation body:** large cards retain the user, stable ID, **Signed by Alice** or the corresponding user, action, and selected provider. Alice's body keeps **AL-1 · Create · provider A** at every carrier. Compact forms preserve ID and explicit **provider A** labels.
- **Carrier:** a registrar-colored surrounding space identifies where a request is submitted or stored. The role tags **Carrier B** and **Selected provider A** sit outside the unchanged Alice body during the comparison beat.
- **Submitted batch:** an immutable ordered container around pending bodies. Its original Bitcoin position stays fixed when copied.
- **Bitcoin commitment:** a compact chip displaying two bound parts: **completed base 9** and **H(a10)**, **H(b10)** or **H(c10)**. The original operation bodies remain off-chain.
- **Replay queue:** five off-chain occurrences grouped by public transaction position, then internal batch position. The two AL-1 slots share one body but occupy different publication positions.
- **Accepted history:** a separate shelf of successful effects. Every miniature uses explicit provider wording. Duplicate input does not produce a second output row.

Keep **Verified through block 9** consistent until a registrar finishes all required verification. Received inputs, authenticated batch bytes, accepted operation effects and a completed cutoff are distinct visible milestones. Introduce one focal change at a time; use the existing pauses for comparison and landing. Picture captions stay in the lower safe area and remain aligned with [opening.vtt](opening.vtt).

## Key frames

Refresh these linked frames after the composition changes.

| Time | Frame |
|---|---|
| 4 seconds | [A's identity retained in block 1](keyframes/frame-004000.png) |
| 50 seconds | [Alice's signed pending body at A](keyframes/frame-050000.png) |
| 81 seconds | [A's ordered submitted batch](keyframes/frame-081000.png) |
| 114 seconds | [The two-part commitments in block 10 order](keyframes/frame-114000.png) |
| 160.5 seconds | [The duplicate matched to accepted AL-1](keyframes/frame-160500.png) |
| 167 seconds | [Three independently verified histories through 10](keyframes/frame-167000.png) |

Additional useful review times are **141.5** for completed byte comparisons, **142.5** for the five-slot queue, **148** for Alice's current-state lookup, **164.5** and **165.5** for B/C's separate checking, and **166.5** for the common result. These are frame review points, not new shots.

## Shot list

Ranges are start-inclusive and end-exclusive. The final common result holds from 166 through 170. Exact caption text and all 35 cue windows live in [opening.vtt](opening.vtt).

### 1. Independent registrations — 0–24 seconds

**Question:** What becomes public when a registrar joins?

**Framing and motion:** Three registrar positions sit above the gold Bitcoin strip. A is introduced at 0 and its identity lands in block 1 at 4. B is introduced at 8 and lands in block 3 at 12. C is introduced at 16 and lands in block 5 at 20. After each landing, its identity label remains inside its mined receipt; the registrar badge stays separate above it. Earlier receipts persist as later identities register.

**Before → after:** No illustrated registrations → three distinct public identity records. No DID creation occurs. The separate receipts show independent registration without a central registrar.

**Caption beats:** 0–4 introduces the registrars and shared history; 4–8 records A at block 1; 8–16 records B at block 3; 16–24 records C at block 5.

### 2. Verify an empty shared base — 24–34 seconds

**Question:** What history is already complete before requests arrive?

**Framing and motion:** Give A/B/C equal prominence. Reveal **Verified through block 9**, three registered identities and zero DID lifecycle operations. Hold the completed, empty result. Block 9 is a cutoff in this illustrative method history.

**Before → after:** Registered identities → each registrar has verified the same empty lifecycle prefix through 9. This completed base is reused later inside each compact commitment.

**Caption beats:** 24–29 separates registered identities from DID operations; 29–34 states complete verification through block 9.

### 3. Alice's signed request — 34–54 seconds

**Question:** What is signed, and what does the provider choice mean?

**Framing and motion:** Alice is left, A's inbox right. Reveal the large card during 34–40 with **AL-1**, **Signed by Alice**, **Create** and **provider A**. During 40–44, hold on the selected provider: A is her DID document service, and that choice is part of the signed body. Transfer the whole unchanged body into A during 44–48. During 48–54, hold on **Pending · not yet accepted**.

**Before → after:** No user request → A holds Alice's whole signed creation request off-chain. Accepted history remains empty and the completed cutoff remains 9. A signer, selected provider and carrier are separate roles even though Alice selects and submits through A here.

The **54-second preview** ends on this landed pending state.

### 4. Different users and a redundant submission — 54–76 seconds

**Question:** Can one signed request use another carrier?

**Framing and motion:** Return to A/B/C's fixed positions. Alice's original card remains at A. Maya's signed MA-1 lands at A at 56, Ben's signed BE-1 at B at 62, and Cleo's signed CL-1 at C at 67. Introduce one at a time and retain all landed cards.

Alice's matching AL-1 travels to B during 70–73. During 73–76, hold both bodies and emphasize their identical ID, signature attribution and provider A. Place **Carrier B** and **Selected provider A** outside B's copy so role labels do not look like altered operation contents.

**Before → after:** One pending request → five pending submission occurrences containing four distinct bodies. B carries the second AL-1 while its provider selection stays A.

### 5. Seal ordered submitted batches — 76–96 seconds

**Question:** What bytes and order are fixed?

**Framing and motion:** Use separate A/B/C close-ups with recognizable registrar badges. Container boundaries close around pending signed bodies. Numbered internal slots make order visible.

| Seconds | Action and result |
|---|---|
| 76–84 | A aligns AL-1 then MA-1; seals a10 at 82 and holds. |
| 84–90 | B aligns BE-1 then identical AL-1; seals b10 at 88 and holds. |
| 90–94 | C seals c10 around CL-1 at 94. |
| 94–96 | Return to all three batches against completed base 9. |

**Before → after:** Loose pending submissions → immutable a10=[AL-1, MA-1], b10=[BE-1, AL-1], c10=[CL-1]. Sealing adds no accepted creation. Bitcoin transaction positions have not appeared yet.

### 6. Commit the base and batch to Bitcoin — 96–118 seconds

**Question:** What enters Bitcoin?

**Framing and motion:** Keep full source batches above the gold Bitcoin band. Each departing chip has two bound fields: **completed base 9** plus its symbolic submitted-batch commitment. Their silhouette and scale differ from operation bodies.

H(a10)'s chip travels during 97–99, H(b10)'s during 101–103, H(c10)'s during 105–107. Pending source cards remain stored throughout. Block 10 is shown mined at 108. Reveal a10 at tx 3 at 108, b10 at tx 8 at 110, c10 at tx 12 at 112, then hold the completed public order during 114–118.

**Before → after:** Three off-chain batches → unchanged stored bytes plus compact ordered anchors binding the completed base and each new batch. The individual payload bodies do not enter Bitcoin. These independently constructed anchors do not pre-certify complete block-10 execution.

**Caption beats:** 96–101 names the two bound parts; 101–108 keeps full bodies off-chain and pending; 108–114 establishes public positions; 114–118 connects batch order and internal order.

### 7. Obtain all required inputs — 118–138 seconds

**Question:** Which data must each registrar have before checking?

**Framing and motion:** A's input shelf has reserved rows for its own a10 and fetched b10/c10. B/C source copies remain visible. Use full-batch transfers with original descriptors and positions.

| Seconds | Delivery |
|---|---|
| 119–122 | A receives complete b10 from B. |
| 123–126 | A receives complete c10 from C. |
| 127–129 | B receives a10. |
| 129.5–131.5 | B receives c10. |
| 132–134 | C receives a10. |
| 134.5–136.5 | C receives b10. |
| 136.5–138 | Hold all three complete input shelves, still verified only through block 9. |

**Before → after:** Each has its own batch → each holds a10, b10 and c10. Copying retains the source bytes, exact contents, descriptor and original Bitcoin position. Receipt advances no completed cutoff. These are shared thin lifecycle inputs; ordinary provider document histories remain separate.

### 8. Compare bytes, then replay operations — 138–164 seconds

**Question:** How do five input occurrences produce four creations?

**Framing:** Keep **AT REGISTRAR A**. First place each fetched batch alongside its original compact Bitcoin commitment. After byte authentication, reveal a separate off-chain replay queue. Accepted history occupies a separate output shelf.

| Seconds | Focal change | Visible result |
|---|---|---|
| 138–142 | Compare each actual downloaded batch with its original commitment. a10's byte check resolves at 139, b10's at 140, c10's at 141. | All A's input bytes are authenticated by 141; accepted history is empty. Hold before operation checking. |
| 142–146 | Reveal five off-chain slots, grouped by tx 3, 8, 12 and then internal positions 1/2. Show both AL-1 occurrences as the same signed body at two positions. | The complete ordered replay queue is visible; none of its occurrences has been accepted merely because bytes matched. |
| 146–152 | Keep the queue as a compact ribbon and highlight a10/1. **Batch verified** stays green. Check **User signature**, then **Current DID state**; Alice's lookup shows **Not created yet** before acceptance at 149. | One Alice creation enters accepted history with explicit provider A. Hold the result. |
| 152–155 | Advance the ribbon to a10/2 and run Maya through the signature and current-state checks; accept at 153. | Two accepted creations, both selecting A. |
| 155–158 | Advance to b10/1; check Ben and accept at 156. | Three accepted creations; Ben selects B. |
| 158–161 | Highlight b10/2. Authenticate this AL-1 occurrence and visually match its body with the accepted AL-1. Resolve **Already applied** at 159. | The accepted count remains three. The duplicate stays outside the output shelf. |
| 161–164 | Advance to c10/1; check Cleo and accept at 162. | Four accepted creations with Cleo selecting C. A completes verification through block 10 at 164. |

The queue groups are:

| Batch / public position | Internal position | Body |
|---|---:|---|
| a10 / tx 3 | 1 | AL-1 |
| a10 / tx 3 | 2 | MA-1 |
| b10 / tx 8 | 1 | BE-1 |
| b10 / tx 8 | 2 | AL-1, identical body |
| c10 / tx 12 | 1 | CL-1 |

**Before → after:** Available inputs → matched batch bytes → ordered signature/state checks → four accepted effects. Keep **Batch verified** distinct from operation acceptance. A duplicate is recognized only after this occurrence is authenticated and matched to the successfully applied operation. Original batch contents and publication positions remain unchanged.

### 9. Independent checks, then one common result — 164–170 seconds

**Question:** Why do the other registrars agree?

**Framing and motion:** Return to fixed A/B/C positions. A finishes at 164. B/C's boxes are labeled **Local replay**. During 164–165, show B's own five inputs entering its own checker and yielding four accepted events; B completes at 165. During 165–166, do the same for C; C completes at 166. No accepted-history object travels out of A, and no line connects A's result to theirs.

From 166–170, hold three separately verified accepted histories with AL-1/provider A, MA-1/provider A, BE-1/provider B, CL-1/provider C. Each says **Verified through block 10**.

**Before → after:** A's detailed replay → three complete independent results at the same cutoff. All used the same required inputs and rules. The common result holds for four seconds. No new checkpoint publication, identical proof bytes or provider document replication is implied.

**Final caption, 164–170:** Each registrar checks the same five inputs. All three verify four creations through block 10.

## Review checklist

- Identity labels remain inside their mined block 1/3/5 registration receipts.
- The shared base says verified through block 9 and contains no accepted DID operations.
- Large signed bodies retain signer attribution and selected provider; carrier role tags stay outside the body.
- Both Alice copies select provider A, including when carried by B and in compact accepted rows.
- A's document-service role is introduced only to explain the signed provider choice.
- Each compact Bitcoin commitment binds completed base 9 and a submitted-batch commitment. Full bodies remain off-chain and pending.
- Copies retain complete bytes, source copies, immutable contents and original positions.
- The 139/140/141 byte comparisons are visibly separate from operation acceptance.
- The five queue slots match tx 3/8/12 and internal order 1/2; the two AL-1 slots remain distinct input occurrences.
- Batch verification is already green during replay; the signature and current-state checks govern each effect.
- The first Alice creation follows a not-created lookup; authenticated duplicate AL-1 matches its accepted counterpart and leaves the count at three.
- A/B/C finish at 164/165/166. Only after C finishes is the full common result shown; hold it through 170.
- All 35 caption windows remain aligned, contiguous and at least three seconds long. Inspect the actual export, the 54-second preview, and frames at both full size and 720p.

Recovery, publisher disappearance, selective withholding, competing recoveries, checkpoints and newcomer onboarding remain later sequences. The opening selects no admission or expiry rule for permanently unavailable data. Registry encoding, reorg rules, input pruning, proof statements and real cryptographic verification remain open or simulated as described in the source documents.