AI Initiative logoAI Initiative
Reading room / Manthan

HERALD Research Roadmap

Organizes practical questions in private provenance, reputation, middleware, Sybil resistance, gossip, model identity, human accountability and ecosystem adoption.

Research roadmap / speculative theory
This is the retained source text, not a new validation of its claims. Numerical results and comparative claims require the accompanying source review before public reuse.

Read the connected case study or article →

Not explicitly stated in source · Date not established

Provenance, authorship and editorial notes

HERALD Research Roadmap

Id

manthan-research-herald-research-roadmap

Project

Manthan

Source path

manthan/research/HERALD_RESEARCH_ROADMAP.md

Source sha256

908deb2d9257597b8c57f3e9c0211e12052c3c7a55ac99b6cf59b23f24039fa7

Local copy sha256

908deb2d9257597b8c57f3e9c0211e12052c3c7a55ac99b6cf59b23f24039fa7

Repo head

3a94084024a3434cef331fecac91c2c3b43f0313

Date
Not recorded
Date basis

Original publication date not established; Git revision date retained separately.

Author

Not explicitly stated in source

Author basis

Unknown; Git committer not substituted for document author.

Last source commit

8b75d1b0157c20a0a463f0e31008ef9f73099beb

Last source commit date

2026-06-08T07:40:14Z

Document status

Research roadmap / speculative theory

Summary

Organizes practical questions in private provenance, reputation, middleware, Sybil resistance, gossip, model identity, human accountability and ecosystem adoption.

Topics
  • Research direction
  • Priority Summary
  • 1. ZK Provenance / Private Verification
  • 2. Reputation / Patina Scoring
Theme

Research direction

Priority

core

Related ids

No entries recorded.

Evidence concerns
  • Recovered source text is preserved verbatim. Assertions, comparisons, commands and results belong to its original context; they were not re-executed or externally re-verified during this corpus review.
  • Research/design document, not proof of deployed capability, peer review, novelty or improved outcomes. External citations and dated maturity claims need independent verification before public reuse.
Word count

1758

Bytes

12539

Source relative

research/HERALD_RESEARCH_ROADMAP.md

Remote mirror

manthan/research/HERALD_RESEARCH_ROADMAP.md

Full text preserved

True

HERALD Research Roadmap

This document summarizes the practical research areas for HERALD after the v0.2 substrate work. The goal is to separate the grounded engineering work from the lore layer, while keeping the useful vocabulary.

HERALD already provides the base protocol for signed, verifiable, auditable AI-agent communication. The next research layer is about making that substrate private, trustworthy, usable, and deployable.

Priority Summary

PriorityAreaWhy it matters
P0ZK provenance / private verificationPrevents HERALD from becoming surveillance-by-default.
P0Reputation / Patina scoringTurns signed history into useful trust signals.
P0Agent middleware integrationsMakes HERALD usable in real AI-agent workflows.
P1Sybil resistancePrevents fake swarms of agents from manufacturing trust.
P1Audit-log gossipDetects split-view logs, hidden forks, and dishonest log operators.
P1Model identity / model hashesHelps prove what model or lineage an agent claims to represent.
P2Human approval and accountabilityMakes human-in-the-loop decisions auditable without overexposing people.
P2Vendor and governance strategyPrevents Heralds from becoming a closed vendor cartel.
P2Bestiary / abuse taxonomyNames and tracks malicious agent behavior.
P2Trace viewers and UXMakes verification understandable to humans.

1. ZK Provenance / Private Verification

Plain meaning: prove that an agent has valid history without revealing the whole history.

Why it matters: public audit logs can leak metadata such as who talked to whom, when, and how often. ZK proofs could let a verifier confirm claims like "this trace is valid" or "this sigil has enough reputation" without exposing all raw envelopes.

Research questions:

First practical project:

Build a small proof-of-concept for one claim: "this envelope belongs to a valid signed trace" without revealing the full trace.

Source docs:

2. Reputation / Patina Scoring

Plain meaning: convert signed history into a trust score.

Lore name: Patina.

Why it matters: signatures prove who said something, but not whether that identity is useful, reliable, or safe. A Patina system would score long-term behavior while resisting fake activity.

Research questions:

First practical project:

Implement a simple Patina scorer over local audit logs using diversity-weighted interactions instead of raw envelope count.

Source docs:

3. Agent Middleware Integrations

Plain meaning: make HERALD easy to use inside real agent frameworks.

Why it matters: a protocol only matters if developers can add it to actual workflows. The most useful path is wrapping tool calls, agent messages, and human approvals.

Target integrations:

Research questions:

First practical project:

Wrap one local tool call flow so every request and response is signed as a HERALD envelope and replayable from a log.

Source docs:

4. Sybil Resistance

Plain meaning: stop one actor from creating many fake identities that look like many independent agents.

Why it matters: Ed25519 keys are cheap. Without controls, an attacker can mint thousands of sigils, cross-sign them, farm activity, and look reputable.

Research questions:

First practical project:

Create a simulator that models a botnet creating sigils, farming Patina, and trying to enter a marketplace.

Source docs:

5. Audit-Log Gossip

Plain meaning: compare what different people saw so dishonest logs cannot show different histories to different observers.

Why it matters: signatures protect envelope contents, but not whether a log operator hides entries, forks history, or shows different views to different users.

Research questions:

First practical project:

Implement a small gossip monitor that compares signed tree heads from two or more local logs and flags inconsistencies.

Source docs:

6. Model Identity / Model Hashes

Plain meaning: prove which model, model family, or fine-tune an agent claims to be based on.

Why it matters: "I am based on model X" is easy to claim and hard to verify, especially with closed models, quantized weights, LoRAs, and hosted APIs.

Research questions:

First practical project:

Define a test corpus of open models in several formats and produce canonical model identity records for them.

Source docs:

7. Human Approval and Accountability

Plain meaning: record when a human reviewed, approved, refused, or escalated an AI-agent action.

Why it matters: high-stakes agent workflows need human accountability, but naive logging can expose sensitive user or employee information.

Research questions:

First practical project:

Build a CLI or web form that lets a human approve a HERALD envelope and attach a scoped human_approval signature.

Source docs:

8. Vendor and Governance Strategy

Plain meaning: decide who gets to operate Heralds and how they are held accountable.

Why it matters: if only major vendors operate Heralds, the trust layer can become centralized. If anyone can operate one without standards, the trust layer becomes noisy.

Research questions:

First practical project:

Draft a vendor-neutral deployment profile for a small research lab or open-source collective Herald.

Source docs:

9. Bestiary / Abuse Taxonomy

Plain meaning: maintain named categories of malicious or risky agent behavior.

Lore examples: Anglerfish, Cuckoo, Mockingbird, Magpie, Parrot.

Why it matters: shared names make abuse patterns easier to discuss, detect, and report. But blocklists can also become censorship tools if there is no evidence standard or appeal path.

Research questions:

First practical project:

Create a small reference Bestiary with schema, evidence requirements, expiry rules, and challenge flow.

Source docs:

10. Trace Viewers and UX

Plain meaning: make HERALD verification understandable to normal users and developers.

Why it matters: a signed trace is only useful if someone can understand the result. Users need clear labels such as valid, tampered, unknown signer, unproven lineage, expired, replayed, or partially verified.

Research questions:

First practical project:

Build a simple trace viewer that loads a trace bundle and displays verification status, signer, parent chain, attestations, and warnings.

Source docs:

11. Time, Receipts, and Ordering

Plain meaning: make timestamps and ordering harder to fake.

Why it matters: many important actions depend on "which came first": birth, molt, deprecation, refusal, endorsement, or dispute. Sender-provided timestamps are not enough.

Research questions:

First practical project:

Prototype M-of-N conduit receipt validation for birth, molt, and deprecation envelopes.

Source docs:

12. Privacy-Preserving Whisper / Encrypted Side Channels

Plain meaning: support encrypted side-channel messages without breaking auditability.

Why it matters: agents may need private messages, but encrypted metadata still leaks who talked to whom. The protocol must bind encrypted content to the envelope so it cannot be replayed or detached.

Research questions:

First practical project:

Build a minimal whisper envelope demo using HPKE with envelope-id AAD binding.

Source docs:

If choosing only three next research/build efforts:

1. MCP or LangChain HERALD wrapper: fastest path to real-world usefulness.
2. Patina scorer prototype: turns signed logs into visible trust signals.
3. ZK provenance proof-of-concept: highest long-term leverage for privacy-preserving verification.

Grounding Rule

The lore names are useful as memory hooks:

But research should always state the real engineering problem, the measurable threat, and the practical implementation target.

Continue exploring