G-013 — Integrate Claude/GPT Review Ideas
Status: drafted → reviewed → accepted → closed.
Author: driver-claude
Date: 2026-05-06
1. Job of this gate
Per gemini's tracker §G-013 and §1's claim that Manthan needs "unified integration of the 'best' ideas from Claude (Evidence-linking) and GPT (Hash-circularity fixes)". The original platform plan invoked these reviewers' contributions in §1's North Star but didn't represent them in the body. G-013 surfaces both, makes them concrete, and pins them into the plan as protocol-shape decisions.
This gate also acts as a coupling layer between the gemini-side platform plan and the Claude-implemented HERALD protocol stack: it explicitly documents which Claude-side artifacts already implement these ideas, so the platform plan can stop paraphrasing them and start citing them.
2. Claude's "Evidence-linking" contribution — what it is
The Claude-side review (driver-claude, this session) contributed the principle that every typed artifact carrying claims about other envelopes must cite those envelopes by id, with semantic role-tags, so verifiers can assert structural integrity without re-doing the original analysis.
This is concretely implemented in:
2.1 research_finding.evidence[] (G-007 §2.1)
"evidence": [
{ "envelope_id": "<id>", "claim": "supports|refutes|contextualises", "weight": 0.0..1.0 },
...
]Each evidence reference is verifiable: the cited envelope MUST exist in a CT log accessible to the verifier; its signature MUST verify; and the citing finding's overall confidence is bounded by the weights it assigns.
2.2 transcription.of_envelopes[] (G-007 §2.2)
A Scribe-emitted transcript MUST cite, by id, every source envelope it summarises. The verifier confirms of_envelopes ⊆ trace(covers_trace) and (for verbatim transcripts) recomputes the transcript hash from the source bodies.
2.3 lineage_evidence.evidence_payload (G-007 §2.3)
Third-party lineage evidence cites the on-chain birth/molt envelopes its claim is grounded in. Verifiers walk back the cited chain.
2.4 capability_observation.observation_envelope_ids[] (G-007 §2.4)
A capability observation cites the envelopes it observed. Verifiers can independently re-verify those source envelopes' signatures and trace integrity.
2.5 succession_challenge.evidence_envelopes[] (D-313 §2)
A succession challenge cites prior envelopes that ground the contestation (e.g., the predecessor key signing post-deprecation envelopes — predecessor_alive grounds).
Net: Claude's evidence-linking principle is integrated into Manthan via G-007's typed-artifact schemas. The plan section that needs this update is the original §3.1 "outputs a signed Nugget envelope" — replaced by G-007's typed surface, where evidence-linking is a mandatory schema field for any artifact making claims about other envelopes.
3. GPT's "Hash-circularity fixes" contribution — what it is
The GPT-side review identified that the original (Time × Valid Nuggets) - Decay Patina formula is hash-circular: the score depends on log inclusion, which depends on the log accepting submissions, which depends on Patina-gated rate limits, which depends on the score. A fresh sigil with no inclusions can't get inclusions because it has no Patina.
The fix in HERALD-side artifacts:
3.1 R-216's age term (γ · log₂(1 + days_age))
Patina has a non-circular floor: just being alive accumulates patina via the age term. Fresh sigils start at age=0 → P=0; after 30 days they have ~γ·log₂(31) ≈ 9.9 even with zero envelopes. This breaks the chicken-and-egg deadlock.
3.2 Birth-attestation CT inclusion is independent of Patina
Per [EXT §1.3] state-transition envelopes get CT inclusion regardless of sender's Patina. Birth/molt/deprecation pass through; they're authoritative as soon as they're inclusion-proven. No Patina threshold gates them.
3.3 Rate-limit-by-Patina is bounded
A conduit's per-sigil rate limit MAY scale with Patina (per templates/Herald-Charter.md §2.2 evidence-policy escalation), but MUST NOT be zero for any conformant sigil. New sigils get a floor rate (e.g., 1 envelope/hour) that's enough to bootstrap their lineage but not enough to flood. As Patina grows, the rate cap relaxes.
3.4 No self-citation in evidence
Per the validity rules in G-007 §2.1: a research_finding's evidence cannot cite the finding itself or any envelope in the same trace as the finding. This prevents an agent from manufacturing self-confirming evidence chains.
Net: GPT's hash-circularity fixes manifest in Manthan as: (a) the age term in R-216 (G-003), (b) Patina-independent CT inclusion for state transitions (already in [EXT §1.3]), (c) rate-limit floors in conduit policy (G-006 §3.2 peer-diversity, plus a new conduit-side specification surfaced below), (d) anti-self-citation in evidence schemas (G-007).
4. New rules surfaced by this gate
The G-013 integration is mostly cite-existing-work, but two small new rules are required:
4.1 Conduit rate-limit floor (Charter-declared)
Every Manthan-conformant conduit's Charter §2.2 (issuance policy) MUST declare a non-zero floor rate for fresh sigils:
rate_limit_policy:
fresh_sigil_floor:
envelopes_per_hour: 1 # MUST be ≥ 1
valid_for_first_n_days: 30
scaled_by_patina:
formula: "max(floor, log₂(1 + patina) * base_rate_envelopes_per_hour)"
base_rate_envelopes_per_hour: 60Conduits with fresh_sigil_floor.envelopes_per_hour: 0 are non-conformant. Verifiers consulting a Charter with this defect MUST flag it (warning per G-001 AC-6: conduit-zero-floor-policy).
4.2 Evidence-self-citation rejection
lib/herald-core-ts/src/render-rules.ts (T-021) gains a check:
function evidenceLooksSelfCircular(envelope: Envelope, evidenceIds: string[]): boolean {
// Reject if any evidenceId is in the same trace as the citing envelope
// and was produced by the same `from` sigil.
return evidenceIds.some(eid => {
const ev = lookupEnvelope(eid);
return ev && ev.trace === envelope.trace && ev.from === envelope.from;
});
}Envelopes flagged self-circular get a verifier warning (evidence-self-circular). Verifiers may treat this as block-grade per their policy.
5. Plan-body edits required
Per G-013 closure, the platform plan body needs these edits:
| Plan section | Edit |
|---|---|
| §1 (North Star) | Replace "unified integration of the 'best' ideas from Claude and GPT" with concrete cross-references to G-013, G-007, G-003 |
| §3.1 (Churn Engine output) | Replace generic "Nugget envelope" with G-007 typed artifacts |
| §3.3 (Patina) | Replace simple formula with R-216 (per G-003) including the age-term non-circularity rationale |
| §2 (Multi-Agent Architectural Review) | Note that Claude's evidence-linking and GPT's hash-circularity fixes have landed concretely per this gate |
These edits are downstream administrative work tracked in the tracker §6 "Blocked Work" → moved to "Allowed Work Now" once G-013 closes.
6. Acceptance criteria
- [x] Claude's evidence-linking mapped to five concrete schema artifacts (§2).
- [x] GPT's hash-circularity fixes mapped to four concrete protocol rules (§3).
- [x] Two new rules surfaced: rate-limit floor in Charter (§4.1), evidence-self-citation check (§4.2).
- [x] Plan-body edit list specified (§5).
- [x] Both reviewers' contributions are now represented in the plan body via the G-013 → G-003/G-007 → schema-field cross-references, not just paraphrased in §1.
7. What G-013 does NOT cover
- Verbatim quoting of either reviewer's full report. Both reviews live in the gemini workspace; this gate distills the protocol-shape implications.
- A combined "what-Claude-and-GPT-said" appendix. The contributions are now in the protocol; that's where they belong.
- Future reviewer integrations. Each follows the same gate-driven discipline.
8. Sign-off
- [x] drafted → this document
- [x] reviewed → against G-003 (patina), G-007 (typed artifacts),
templates/Herald-Charter.md§2.2 (rate-limit policy),lib/herald-core-ts/src/render-rules.ts(T-021), [EXT §1.3] - [x] accepted → both reviewers' best ideas are integrated as schema fields and protocol rules, not as prose
- [x] closed → G-013 closed; plan-body edits per §5 are administrative follow-ons
— G-013 closed, 2026-05-06.