HERALD Public Feedback Intake

Use this template for outside review of the HERALD v0.2 draft. HERALD is a draft protocol for signed envelopes, hash-linked traces, attestations, lineage, and discovery; it records what happened, while reputation systems decide what it meant.

Reporter

Name or handle:
Affiliation:
Contact:
May maintainers quote you publicly? yes / no / ask first
Disclosure preference: public issue / private report first / security-sensitive

Feedback Class

Choose the closest class.

Class	Use when the issue concerns
`SPEC`	Minimum normative substrate: identity, envelope format, signatures, verification, conduit basics.
`EXT`	Protocol-layer extensions: molt, audit logs, Herald transparency, capability manifests, multi-signature scoping, discovery profiles.
`CHARTER`	Cultural register, lifecycle rituals, conduit roles, reserved sigils, vocabulary, adoption surface.
`THREATS`	Attack coverage, unaddressed risks, systemic risks, abuse cases, accepted residual risk.
`interop`	Ambiguity likely to make two implementations disagree.
`editorial`	Clarity, spelling, cross-reference, line drift, duplicated concept, naming mismatch.
`process`	Feedback about the manthan contribution/review workflow itself.

Severity

Choose one and explain why.

Severity	Meaning
`critical`	A conforming implementation could be unsafe, unverifiable, or mutually incompatible in a central protocol path.
`high`	A serious attack, ambiguity, or interoperability risk exists, but a workaround is plausible.
`medium`	The draft is misleading, incomplete, or likely to cause inconsistent implementations.
`low`	Editorial, terminology, explanatory, or non-blocking process concern.
`question`	You need clarification and are not yet asserting a defect.

Location

Document:
Section:
Line number or quoted phrase:
Related document/section, if any:
Current text:

Paste the relevant excerpt here.

Claim

State the issue in one sentence.

Example: SPEC §3.6 registers one domain-separation tag while another section names a different version, so signers may produce incompatible signatures.

Evidence

Describe how you found it. Include any proof, implementation attempt, test vector, attack path, or cross-document comparison.

Reproduction steps:
Expected behavior:
Actual behavior:
Why the difference matters:

Proposed Resolution

Choose one.

normative edit: change MUST/SHOULD/MAY behavior.
extension edit: move or clarify behavior in EXT.
charter edit: revise vocabulary, cultural framing, lifecycle ritual, or examples.
threat edit: add, reclassify, or cross-reference an attack.
test/vector: add a conformance case.
no change: document why the current risk is accepted.

Suggested text:

Paste a concrete replacement paragraph, table row, or test-case description if you have one.

Security-Sensitive Reports

If this report enables practical forgery, replay, key compromise, audit-log split view, deanonymisation, large-scale abuse, or bypass of a stated verifier requirement, mark it security-sensitive and do not include exploit-ready detail in a public issue. Provide enough summary for triage, then share full detail privately with the maintainers.

Triage Checklist For Maintainers

Is the report about a property HERALD claims to provide, or about an application-layer judgement HERALD explicitly leaves out?
Does it affect core conformance, an optional extension, the Charter, or the threat model?
Does it need a new TODO task, a direct document patch, a conformance vector, or a no-change rationale?
If the report is about accepted residual risk, is that risk already visible in THREATS.md?
If the report changes public behavior, does README.md still describe the project accurately?

Maintainer Disposition

Status: accepted / needs reproduction / needs design decision / deferred / declined
Assigned task ID:
Reviewer:
Decision date:
Rationale:

Follow-Up Task Stub

| D-XXX | <short title> | pending | <deps or -> | `<output-path>` |

HERALD Public Feedback Intake