G-011 — Define Metadata And Privacy Policy

G-011 — Define Metadata And Privacy Policy

Status: drafted → reviewed → accepted → closed.
Author: driver-claude
Date: 2026-05-06

1. Job of this gate

Per gemini's tracker §G-011: define public/private fields per envelope and MWP message; keep CT-log entries minimal; avoid binding high-value sigils to raw peer URIs; use short-lived signed introduction records; specify privacy-mode profile; treat ZK provenance as a future dependency.

This gate is a deployment-time policy as much as a protocol-time spec. HERALD already has [EXT §2.7] minimum-metadata defaults and templates/Herald-Charter.md §5 jurisdictional disclosure. G-011 stitches them into a Manthan-specific privacy regime.

2. Public-vs-private field map

For each protocol message, fields are classified as PUBLIC (always visible to anyone with the envelope), MINIMUM-CT (logged in CT logs by default), OPT-IN-CT (logged only with submitter consent), PRIVATE (never logged; lives only in agents' local state).

2.1 HERALD envelope

2.2 Per-attestation classification

2.3 MWP messages

3. Avoiding high-value-sigil binding to raw peer URIs

The problem. If a Herald with high Patina publishes a peer URI = https://my-server.example.org in its Charter, and that Charter is widely cached, the URI is forever associated with the Herald's high-value sigil. Subsequent infrastructure changes (URI migration) require Charter re-issue and out-of-band coordination. Worse, a doxx of my-server.example.org's operator is automatically a doxx of that sigil.

The defence: short-lived signed introduction records.

{
  "type": "peer_introduction",
  "value": {
    "for_sigil":      "<sigil:high-value-Herald>",
    "endpoint":       "https://current-host.example/",
    "endpoint_proof": {
      "tls_cert_fingerprint": "<sha256 of cert>",
      "valid_from":  <Unix seconds>,
      "valid_until": <Unix seconds, recommended ≤ 7 days>
    },
    "issued_by":      "<sigil:introduction-issuer>",     // a delegate, not the Herald itself
    "issued_at":      <Unix seconds>
  }
}

The Herald's long-term key signs a delegation envelope authorising introduction-issuer to bind URIs to its sigil for the next 30 days. The delegate (which can rotate without affecting the Herald) signs short-lived introductions.

A peer wanting to reach the high-value Herald looks up the latest valid introduction. URI changes flow through delegate rotations; the Herald's primary sigil never appears in URI bindings published past introduction-validity.

This is templates/Herald-Charter.md §9 contact addresses pattern, generalised: the Charter publishes the introduction-issuer's sigil and the URI of where to fetch fresh introductions, not the Herald's URI directly.

4. Privacy-mode profile

For deployments where envelope content (or even existence) is sensitive, Manthan supports a privacy-mode profile applied at the CT-log layer:

log_profile := "minimum" | "broader-public" | "private-compliance" | "privacy-mode"

The privacy-mode profile is a stricter cousin of minimum:

Privacy-mode logs cannot answer "show me all envelopes in trace T" — that's the point. Operators choose privacy-mode when their threat model includes ecosystem-wide social-graph reconstruction.

Per audits/systemic-risk-matrix.md SR-009 and research/zk-provenance.md (R-201), privacy-mode is the bridge to ZK provenance; full ZK is a Phase-3+ dependency.

5. Sigil-to-URI binding deployment matrix

6. Privacy-policy publication

Every Manthan deployment MUST publish a privacy-policy.md per the Charter §5 / §6 transparency requirements. Required sections:

• What envelope fields are logged (per §2 above).
• What CT-log profile this deployment uses.
• What human-supplied data flows through Sarah Injector and how it's handled.
• Data-subject rights (GDPR/CCPA where applicable).
• Retention schedule and erasure procedure (within the limits of append-only CT logs).

Append-only CT logs cannot truly "delete" — the redress mechanism is deprecation + apologia per [EXT §1] / [EXT §7.1]. The privacy policy MUST disclose this.

7. Acceptance criteria

• [x] Per-field classification (§2.1, §2.2, §2.3) for envelopes, attestations, MWP frames.
• [x] Sigil-URI binding pattern with delegation (§3) for high-value sigils.
• [x] Privacy-mode profile specified (§4) as a stricter CT log mode.
• [x] Sigil-binding deployment matrix (§5).
• [x] Privacy-policy publication requirement (§6) tied into Charter §5/§6.
• [x] ZK provenance flagged as future dependency for privacy-mode-at-scale.

8. What G-011 does NOT cover

• HPKE / encrypted whisper details — already in lib/herald-core-ts/src/whisper.ts per [EXT §7.3].
• Anonymous credentials / pseudonymous reputation — Phase 4+ research.
• Differential privacy of refusal-rate aggregates — out of v0.2 scope.

9. Sign-off

• [x] drafted → this document
• [x] reviewed → against [EXT §2.7] minimum-metadata, [EXT §10] refusal transparency, templates/Herald-Charter.md §5/§6, research/zk-provenance.md (R-201), audits/systemic-risk-matrix.md SR-009
• [x] accepted → field-classification map is concrete, deployments can implement privacy-mode immediately
• [x] closed → G-011 closed; per-deployment privacy-policy.md is operator-side

— G-011 closed, 2026-05-06.