Skip to content

demo.md

Latest commit

 

History

History
479 lines (292 loc) · 10 KB

demo.md

File metadata and controls

479 lines (292 loc) · 10 KB

SpineFrame Demo Script

This file is the master script for the SpineFrame product demo.

For the recording workflow, see demo_recording_checklist.md.

Core Message

SpineFrame makes workflow changes reviewable, replayable, and defensible.

The product proof is:

  • start from an approved baseline
  • trace one claim back to evidence
  • fork from the exact stage that changed
  • reuse prior work
  • block export until review
  • diff the changed run against the approved state
  • approve the new state
  • export a signed evidence package
  • verify independently

The newest proof layer is:

  • verify what the agent claimed against what the signed provenance record says actually happened

Use This Exact Demo Setup

Use the compliance pipeline only.

Use these exact runs and states in the live web UI:

  • approved baseline:
    • SOC 2 Type II audit for Acme Cloud (Engineering team)
  • completed but unapproved fork:
    • ISO 27001 audit for Acme Cloud (Engineering team)
  • fork point:
    • Map Controls
  • fork instruction:
    • Map to ISO 27001 controls instead of SOC2

Preferred environment:

  • live UI at spineframe.xyz
  • role: Admin
  • evidence sources:
    • GitHub repo: Ratnaditya-J/acme-cloud-evidence
    • filesystem: /data/evidence

Optional second environment for the verification feature:

  • one run with a final output artifact that overclaims what happened
  • one terminal already in the repo with spineframe verify-claims available

Demo Versions

Use three cuts from the same story.

  1. Main acquisition cut — 90 seconds
  2. Full product cut — 2:30 to 3:00
  3. CISO add-on — 60 to 90 seconds

The first two are the main product story. The third is the newest trust-scoring feature and should usually be a second clip, not part of the main 90-second cut.

Main Acquisition Cut — 90 Seconds

This is the canonical short demo.

Beat 1: Approved Baseline (0:00-0:10)

Open on the approved SOC 2 run. Do not start by creating a run.

Show:

  • run title
  • approved state
  • signed or verifiable state

Caption:

  • Approved. Signed. Verifiable.
  • Start from an approved baseline, not a one-off run.

Beat 2: Provenance Trace (0:10-0:25)

Open one claim or finding from the approved SOC 2 run. Trace it through:

  • claim
  • chunk
  • source
  • URL or source object

Caption:

  • Every claim traces to evidence.
  • Claim -> chunk -> source -> URL

Beat 3: Fork the Approved Run (0:25-0:35)

From the approved SOC 2 run:

  • click Fork
  • choose Map Controls
  • change only the framework
  • show the ISO 27001 fork start

Caption:

  • Fork from the exact point that changed.
  • No need to rerun the whole workflow.

Beat 4: Reuse Prior Work (0:35-0:45)

Show the ISO 27001 fork lineage or stage view. Make the reuse visible:

  • skipped stages
  • reused artifacts
  • lower cost or shorter runtime

Caption:

  • Fork. Reuse. [X] stages skipped.
  • SOC2: $[A]. ISO: $[B].

Use the real run numbers.

Beat 5: Policy Block (0:45-1:00)

On the unapproved ISO 27001 fork:

  • click Export button
  • show "Export Blocked" modal (approval required)

Caption:

  • Policy blocks export until review.
  • High-stakes changes do not ship silently.

Beat 6: Diff and Approve (1:00-1:15)

Open the compare view between:

  • approved SOC 2 baseline
  • unapproved ISO 27001 fork

Show:

  • changed claims
  • changed sources
  • changed output

Then approve the ISO 27001 run.

Caption:

  • See exactly what changed.
  • [X] claims changed. [Y] sources added.

Follow with:

  • Approval is recorded, not assumed.
  • Who approved, when, and under which state.

Beat 7: Signed Export and Verification (1:15-1:30)

From the newly approved ISO 27001 fork:

  • click Export button — "Package Exported" modal shows signer + root hash
  • show verification

Caption:

  • Signed. Verified. Independent.
  • Anyone can check the signed output.

Closing Card (1:30-1:35)

Caption:

  • Reviewable. Replayable. Defensible.
  • SpineFrame for high-stakes AI workflows.

Full Product Cut — 2:30 to 3:00

Same story, with more breathing room and a little more explanation.

1. Setup the state (0:00-0:15)

Open on the approved SOC 2 baseline.

Say or caption:

"This run is already approved and signed. We are not starting from scratch."

2. Trace one finding back to evidence (0:15-0:40)

Use the provenance viewer.

Show:

  • the finding or claim
  • source document
  • one concrete upstream record from GitHub or filesystem

Talking point:

"This is not just observability. The output is inspectable down to the evidence source."

3. Fork to ISO 27001 from Map Controls (0:40-1:00)

Show the fork action itself.

Talking point:

"The evidence base stays fixed. We are only changing the framework and the downstream analysis."

4. Show reuse and stage-level economics (1:00-1:20)

Show:

  • skipped stages
  • cost difference
  • lineage / DAG depth

Talking point:

"This is where SpineFrame stops looking like a wrapper. The engine knows what can be reused."

5. Show the policy block (1:20-1:35)

Attempt export before approval.

Talking point:

"A high-stakes change does not ship silently. The runtime enforces the review boundary."

6. Open the diff (1:35-2:00)

Stay on the compare view a little longer.

Show:

  • one changed claim
  • one changed source set
  • one changed output block

Talking point:

"The question is not just what the new output says. The question is what changed from the last accepted state."

7. Approve the forked run (2:00-2:15)

Show:

  • approval action
  • approved-by metadata
  • timestamp

Talking point:

"Approval becomes part of the run record."

8. Export and verify (2:15-2:35)

Show:

  • signed package export
  • verification success

Talking point:

"You do not have to trust the UI. The exported evidence can be checked independently."

9. Close (2:35-2:50)

Use one sentence:

"SpineFrame gives teams a reviewable, replayable, and defensible runtime for agent workflows."

Optional CISO Add-On — Claims vs. Reality (60-90 seconds)

This is the newest product proof and should usually be a second clip.

Do not overload the main 90-second demo with it.

The One-Line Pitch

"Your agent says it completed the task. SpineFrame checks whether that claim matches the signed provenance record."

Why This Matters

This is stronger than ordinary tracing.

The question is no longer:

  • what spans were emitted?

The question becomes:

  • did the agent's summary accurately describe what actually happened?

Scenario

Use a run whose final output overclaims its own execution.

Example pattern:

  • the output says the agent searched, fetched, analyzed, and completed the package
  • the provenance record shows:
    • a tool call failed
    • fewer sources were fetched than claimed
    • part of the workflow never actually completed

Step 1: Run claim verification

spineframe verify-claims <run_id> --config providers.json

Show the extraction summary:

Verifying claims for run <run_id> (source: report.json)
  Confidence threshold: 0.7
  Strictness: fuzzy
  Extracted 6 claim(s)

Step 2: Show the mismatch categories

The important categories are:

  • GROUNDED
  • UNGROUNDED
  • CONTRADICTED
  • LOW CONFIDENCE

Show the summary block:

Summary:
  Total claims extracted:  6
  ✓ GROUNDED:        0
  ? UNGROUNDED:      1
  ✗ CONTRADICTED:    3
  ⚠ LOW CONFIDENCE:  2
  Grounding score:   0.0%

Step 3: Show one fabricated claim and one contradicted claim

Use examples like:

  • ungrounded search activity
  • contradicted source count
  • contradicted tool success claim

What matters is not the exact wording. What matters is that the CLI shows the claim and the signed reality side by side.

Step 4: Show machine-readable output

spineframe verify-claims <run_id> --output json

Call out:

  • grounding_score
  • grounded_count
  • contradicted_count

Talking point:

"This is ready to feed into security, GRC, or policy automation tooling."

Step 5: Show cryptographic verification

spineframe verify-claims <run_id> --signature

Talking point:

"The proof is not just analytical. It is tied back to the signed provenance bundle."

Close

Use one line:

"SpineFrame is not just tracing what the agent did. It verifies whether the agent told the truth about what it did."

Exact Talking Points

Use these verbatim if needed.

Main product line

"SpineFrame starts from an approved baseline, makes changes reviewable with diff and approval, and exports something another team can verify later."

Provenance line

"This output is inspectable. We can trace a claim back to the evidence that supports it."

Fork line

"We are not rerunning the whole workflow. We are branching from the exact stage that changed."

Policy line

"The runtime stops export until a human reviews the changed state."

Verification line

"You do not have to trust the UI. The signed package can be verified independently."

Claims vs. reality line

"The agent can claim it completed the task. SpineFrame checks that claim against the signed execution record."

What The Demo Must Prove

The main demo must prove:

  • output is inspectable
  • prior work is reusable
  • changes are reviewable
  • approval is structural, not informal
  • signed export is real
  • verification is independent

The CISO add-on must prove:

  • agent output can be checked against reality
  • overclaiming is detectable
  • trust score is machine-readable
  • the proof is anchored in signed provenance

Audio

Recommended:

  • one opening line
  • then silence plus captions

Opening line:

"This report was generated, reviewed, forked, and re-approved. Here's the audit trail."

For the CISO add-on:

"Now let's verify whether the agent's own summary matches what actually happened."

Caption Rules

  • Keep each main caption under 6 to 8 words.
  • Keep each subline under 10 to 12 words.
  • Use real numbers from the recorded run.
  • Keep each caption on screen for at least 2.5 seconds.
  • Let the UI prove the statement.
  • Burn captions into the final video.