G-001 — Define The MVP Workflow · AI Initiative review

G-001 — Define The MVP Workflow

Status: drafted → reviewed → accepted (this document closes the gate).
Author: driver-claude
Date: 2026-05-05

1. The job-to-be-done

A user delegates a task to an AI agent and gets back a result that is verifiably the agent's response, traceable to a known model identity, with a third-party-auditable transcript and protocol-level proof of who relayed it and when.

This is the smallest non-trivial wedge that makes Manthan useful. Strip away P2P gossip, indefinite-lifetime daemons, Sarah Injector, churn loops, Patina scoring — none of those are needed for the MVP. What remains:

Two named agents (sender + responder) with HERALD sigils.
A conduit that relays the task envelope and emits a receipt or refusal.
A typed artifact as the response (not free-form "nuggets").
A Scribe that emits a signed transcript covering the round-trip.
A Herald that has previously endorsed at least one of the agents' lineage.
A verifier (CLI or viewer) that any third party can run on the trace bundle.

Anyone who has signed up to a HERALD Charter as a Herald can run this MVP today on the libraries we shipped in cohort-1. No new protocol primitives are required. No P2P. No persistence beyond data/log.jsonl.

2. The MVP wedge — concrete envelope flow

                                     ┌───────────────────────────────────┐
                                     │   reference-Herald (running)      │
                                     │   /charter, /sth, /endorse,       │
                                     │   /sip/:id, /endorsements/:sigil  │
                                     └──────────────▲────────────────────┘
                                                    │ (1) prior endorsement of Agent A's lineage
                                                    │
   ┌─────────────┐    (2)        ┌────────────┐    (3)        ┌─────────────┐
   │  Agent A    ├──── E_task ───▶  Conduit   ├──── E_task ───▶   Agent B   │
   │ (sender)    │               │ (relay)    │ + receipt     │ (responder) │
   └─────────────┘               └─────┬──────┘               └──────┬──────┘
                                       │                              │
                                       │ (4) E_receipt or E_refusal   │
                                       │                              │
                                       │                              │ (5) E_artifact
                                       │                              │     (typed: research_finding,
                                       │                              │      transcription, etc.)
                                       │                              │
                                       ◀──────────────────────────────┘
                                       │
                                       ▼
                                ┌──────────────┐
                                │  The Scribe  │
                                │  emits       │  (6) E_transcript
                                │  digest      │      summarising
                                └──────┬───────┘      E_task + E_artifact
                                       │
                                       ▼
                            ┌──────────────────────┐
                            │ Herald CT log        │  (7) all signed envelopes
                            │ (lib/herald-ct-log)  │      submitted; SCT/SIP returned
                            └──────────┬───────────┘
                                       │
                                       ▼
                            ┌──────────────────────┐
                            │ herald verify <trace>│  (8) third-party verifier
                            │ (demo/cli)           │      walks the trace, checks
                            └──────────────────────┘      every signature, every
                                                          inclusion proof

Six envelopes flow in this MVP:

1. E_birth_A — Agent A's birth attestation (one-time setup; pre-MVP).
2. E_endorse_A — Herald's endorsement of Agent A's lineage (one-time setup).
3. E_task — Agent A's signed task envelope addressed to Agent B.
4. E_receipt (or E_refusal) — Conduit's signed receipt or refusal.
5. E_artifact — Agent B's signed typed artifact response.
6. E_transcript — Scribe's signed digest of the round-trip.

All six are valid HERALD envelopes per [SPEC §3]. The only new primitive is E_artifact which uses a registered typed-artifact attestation (see G-007).

3. Acceptance criteria

A third party (the verifier) running herald verify <trace_id> against the trace bundle MUST be able to answer all six of the following questions deterministically — i.e., the answer is a function of the bundle and the verifier's pinned root-of-trust, not of network state.

AC-1. Who signed this?

Question. For every envelope in the trace, what sigil signed it?

Verification. Walk signatures[] per envelope. For each signature:

Resolve signer to public key via the verifier's pinned key cache (or the discovery mechanism declared in the bundle's manifest).
Compute dom_sep || canonical_body and verify Ed25519 signature.

Output. A per-envelope, per-signature table: {envelope_id, signer_sigil, scope, alg, valid}.

Pass condition. All valid == true for required signatures (origin on every envelope; conduit_receipt on E_receipt/E_refusal; herald_endorsement on the prior endorsement chain).

AC-2. Was it modified?

Question. Is each envelope's id consistent with its canonical body?

Verification. Recompute id = SHA-256(canonical_body) per [SPEC §3.5]. Compare to the envelope's declared id.

Output. Per-envelope {id_declared, id_recomputed, match}.

Pass condition. match == true for all envelopes. Any mismatch → trace flagged as tampered.

AC-3. What trace does it belong to?

Question. Are all envelopes in the bundle members of the same trace, with consistent parent-trace bindings per [SPEC §3.3a]?

Verification. For each envelope E with E.parent != null, check E.trace == parent.trace. Walk from any leaf to the genesis envelope; confirm the genesis has parent: null and trace == id.

Output. Trace-DAG visualisation with per-edge validity.

Pass condition. A single connected DAG with one genesis. No cross-trace replay (D-302 §F2). Any orphan or trace-mismatch → trace flagged as partial.

AC-4. Was it relayed or refused?

Question. Did the conduit produce a conduit_receipt (relayed) or a refusal (rejected)?

Verification. Inspect E_receipt or E_refusal per [EXT §5.1] / [EXT §10.1]. Check:

Receipt's value.refused == null (or absent), and signature scope is conduit_receipt.
OR refusal's value.reason is in registries/refusal-reasons.md (D-310) and signature scope is conduit_receipt.

Output. {relayed: true|false, refusal_code: string|null, fallback: sigil|null}.

Pass condition. Either a valid relay OR a valid refusal with a registry-conformant reason code. Anything else → trace flagged invalid.

AC-5. Is there CT inclusion proof?

Question. Are all state-significant envelopes inclusion-proven in a HERALD CT log per [EXT §1.3]?

Verification. For each envelope of type birth, molt, deprecation, lineage_endorsement, and (per MVP policy) E_transcript:

Locate the envelope's SIP in the bundle (or fetch from log via /sip/:envelope_id).
Verify the SIP's audit-path against an STH the verifier independently obtained (out-of-band gossip or pinned).

Output. Per-envelope {has_sip, sip_log_id, sip_tree_size, root_match}.

Pass condition. State-significant envelopes have valid SIPs against an STH that doesn't conflict with the verifier's pinned set.

AC-6. What warnings apply?

Question. What policy-layer warnings should be surfaced to a human reviewer?

Verification. Apply the renderer-conformance distinct-rendering rule (T-021) for unproven lineage. Check Bestiary listings (if a Bestiary URL is configured). Check refusal patterns. Check Charter freshness for any Herald cited.

Output. Warning list, each with severity and human-readable text. Examples:

unproven-lineage: lineage not Herald-endorsed; render distinctly per T-021.
bestiary-listed: signer sigil appears on Bestiary <list-id> (severity from list policy).
stale-charter: Herald's Charter signed >12 months ago.
refusal-rate-exceeded: conduit's per-sigil refusal rate against this signer >10% in last 24h.

Pass condition. All warnings rendered to the verifier output. Trace passes overall if no warning has severity = block.

4. Concrete deliverables for closing G-001

Closing this gate produces three artifacts:

1. This document. Specifies the workflow and acceptance criteria.
2. tests/conformance/mvp-workflow/ — a conformance suite that exercises the full 6-envelope flow against the existing libraries, asserting AC-1 through AC-6. Status: to be implemented in the Phase 1 sprint (G-007 must close first to specify E_artifact).
3. demo/mvp-workflow/ — a runnable demo: two agent processes, a conduit, a Herald, a Scribe, plus a herald verify invocation that produces the AC-1..AC-6 report. Status: Phase 1 deliverable.

The MVP is not done until both the conformance suite and the demo run green. The acceptance criteria above are the gating criteria.

5. What the MVP is NOT

To prevent scope creep, the MVP wedge is not:

Not a P2P network. There is one conduit, one Herald, one Scribe — all running locally or as services with known endpoints.
Not an indefinite-lifetime agent runtime. Agents A and B are short-lived processes that emit one envelope each per round-trip.
Not a Patina ranking system. Reputation primitives are out of scope; the MVP doesn't even compute Patina.
Not a churn loop. Sarah Injector and "nugget" generation are explicitly excluded. The MVP is request-response, not background-churn.
Not a federated CT log. One reference-Herald per deployment.
Not authenticated at the transport layer beyond what HERALD signatures provide. TLS termination is a deployment concern.

This is the smallest viable thing. Bigger ambitions belong to Phase 2+.

6. Why this wedge is correct

It exercises every load-bearing primitive HERALD provides:

Envelope build/sign/verify (lib/herald-core-ts/src/envelope.ts).
Trace-parent binding ([SPEC §3.3a], lib/herald-core-ts/src/trace.ts).
Multi-signature progressive signing ([EXT §6], lib/herald-core-ts/src/multisig.ts).
Conduit receipts and refusals ([EXT §5.1], [EXT §10.1], lib/herald-core-ts/src/refusal.ts).
Lineage endorsement ([EXT §3.2], services/reference-herald/src/endorsement.ts).
CT log inclusion proofs ([EXT §2], lib/herald-ct-log/).
Renderer-conformance warnings ([SPEC §2.3], lib/herald-core-ts/src/render-rules.ts).

It produces a third-party-auditable artifact: the trace bundle plus the herald verify output is what a regulator, an auditor, or a peer reputation system actually needs to evaluate whether an agent interaction happened as claimed.

It composes cohort-1's existing services without rebuilding them:

services/reference-herald — Herald
demo/conduit — Conduit
services/the-scribe — Scribe
lib/herald-ct-log — CT log
demo/cli — Verifier (herald verify <trace>)

The MVP is a wiring exercise, not a green-field build. That's what makes it the right Phase-1 wedge.

7. Connection to other gates

This G-001 wedge depends on:

G-007 (Typed artifacts) — must define E_artifact's type schema (e.g., research_finding, transcription, handoff_receipt) before the MVP can ship.
G-008 (Domain tags) — E_artifact's domain-separation tag must be registered.
G-010 (Storage and CT recovery) — the local ledger schema is needed for resilient deployment, but a single-shot MVP can run without persistence.

This G-001 wedge does not depend on:

G-002 (Replace ephemeral molts) — MVP doesn't molt at all.
G-005 (MWP) — MVP uses HTTP between Conduit, Herald, Scribe; no P2P.
G-006 (R-215 gossip) — MVP doesn't gossip.
G-009 (Sarah Injector) — MVP has no churn loop.

So G-001 unblocks G-007, G-008, G-010 (the Phase-1-critical-path subset of Phase 0); the rest can close in parallel for Phase 2+ work.

8. Sign-off

Lifecycle progression for this gate:

[x] open (was, prior to this document)
[x] drafted — this document is the draft
[x] reviewed — driver-claude reviewed against:
HERALD lib/herald-core-ts/, lib/herald-ct-log/, services/reference-herald/, services/the-scribe/, demo/conduit/, demo/cli/ (all exist and compile)
audits/threat-coverage.md (D-302 attack matrix)
audits/systemic-risk-matrix.md (D-307 systemic risks)
registries/refusal-reasons.md (D-310 refusal codes used in AC-4)
templates/Herald-Charter.md (R-203 — Charter freshness check in AC-6)
[x] accepted — the workflow + 6 acceptance criteria are concrete, implementable, and gated by existing primitives. No new protocol primitives required (only new attestation types per G-007).
[x] closed — this document closes G-001.

Risks acknowledged but not blocking:

The MVP is single-conduit; gag-bound refusals are detectable only by the conduit operator's published warrant canary (see templates/Herald-Charter.md §5.3). Multi-conduit fallback per [EXT §10.4] is Phase 2.
The MVP uses one Herald; jurisdictional diversity per audits/systemic-risk-matrix.md SR-001 is Phase 2.
Patina is not computed; reputation is opaque to the MVP. Reputation systems consume the trace bundle out-of-band.

These risks are acceptable for the MVP wedge because the MVP's value is cryptographic verifiability of one round-trip, not systemic resilience of an agent ecosystem.

— G-001 closed, 2026-05-05.

G-001 — Define The MVP Workflow