MVP Workflow Demo (Manthan G-001)

Phase 1 deliverable per the Manthan platform tracker. Implements G-001 §2's six-envelope wedge end-to-end in a single Node process; verifies the resulting trace against G-001 §3's six acceptance criteria.

What this demonstrates

A third-party-verifiable AI-agent task delegation:

1. Agent A asks Agent B a question, signed under Agent A's sigil.
2. A Conduit relays the request and emits a signed conduit_receipt.
3. Agent B accepts the task with a typed handoff_receipt and returns an answer.
4. A Scribe emits a signed transcription summarising the round-trip.
5. A Herald has previously endorsed Agent A's lineage.
6. Anyone with the resulting trace bundle can verify all six envelopes cryptographically — without trusting any participant.

No P2P. No persistence beyond the output JSON. No churn engine. No Patina computation. The smallest viable thing.

Run it

npm install
npm run demo    # emits 6 envelopes, writes out/trace-bundle.json
npm run verify  # runs herald-verify against the bundle, reports AC-1..AC-6
npm test        # runs the conformance suite (8 assertions)

What the verifier checks

AC	Question	How
AC-1	Who signed each envelope?	Walks `signatures[]`; verifies each Ed25519 signature against the claimed `signer`'s pubkey from the bundle.
AC-2	Was each envelope modified?	Recomputes `id = sha256(canonical_body)` and compares to the declared `id`.
AC-3	What trace does each envelope belong to?	Walks the parent-trace DAG; asserts [SPEC §3.3a] `E.trace == parent.trace` invariant; confirms single genesis.
AC-4	Was E_task relayed or refused?	Inspects `E_receipt`/`E_refusal`; refusal codes must be in `registries/refusal-reasons.md`.
AC-5	Is there CT inclusion proof?	(Stubbed in this MVP — production runs verify SIPs against a live CT log.)
AC-6	What warnings apply?	Surfaces lossy-transcript, unproven-lineage, etc.

Roles and envelopes

Pre-MVP setup envelopes:
  E_birth_A       Agent A's birth attestation
  E_endorse_A     Herald's lineage_endorsement of Agent A

Task trace envelopes (genesis = E_task):
  E_task          Agent A → Agent B   "what is the capital of France?"
  E_receipt       Conduit → Agent A   conduit_receipt over E_task
  E_artifact      Agent B → Agent A   handoff_receipt + answer ("Paris")
  E_transcript    Scribe → sigil:none transcription summarising E_task + E_artifact

What this is NOT

Not a P2P network — six envelopes in one process.
Not a daemon — exits after producing the bundle.
Not Patina-aware — reputation is computed elsewhere.
Not authenticated — any sigil can play any role in this demo.
Not encrypted — payload is plain CBOR.

These are intentional MVP scope boundaries per G-001 §5.

Bundle format

out/trace-bundle.json is a self-contained verifiable package:

{
  "manifest": { "version": "manthan-mvp-trace-bundle-1", ... },
  "pubkeys":  [ { "sigil": "...", "pubkey_pem": "..." }, ... ],
  "envelopes": [
    { "role": "E_birth_A",   "envelope": { ... } },
    { "role": "E_endorse_A", "envelope": { ... } },
    ...
  ]
}

The bundle is what herald verify <bundle> consumes. For production, a tools/trace-bundler.ts (G-004 §4.2) walks a live CT log to assemble a comparable bundle from any leaf envelope.

Cross-references

manthan-platform/gates/G-001-mvp-workflow.md — the spec this demo implements
manthan-platform/gates/G-007-typed-artifacts.md — typed artifacts used in E_artifact, E_transcript
manthan-platform/gates/G-008-domain-tag-registry.md — domain tags now registered in EXT §13
lib/herald-core-ts/ — protocol primitives
services/reference-herald/ — the production-shaped Herald (this demo is single-process equivalent)

MVP Workflow Demo (Manthan G-001)