FAQ

A signed, per-reporter hash-chained accusation: a small object one party files against another, naming a category of harm and citing at least one existing receipt or envelope by hash — with the accusation itself never adjudicated by the primitive that signs it.

protocol, reporter_id, accused_id, accused_role (agent/principal), category, evidence_refs, narrative, delegation_position, delegation_ref, prev_hash, issued_at, sig, and pubkey. A document with any additional or missing member is not a report and fails verification. See What is an Abuse Report for the normative table.

Because abuse between a principal and an agent can run either way. accused_role lets one schema cover an agent accused of deceptive output or resource abuse and a principal accused of injection or forced capability extraction, rather than needing two separate report types for a distinction one field can carry.

accused_role is ontology — is the accused a computational agent or a human principal? delegation_position is topology — where does the accused sit relative to the filer in the delegation chain: upstream, downstream, or lateral (a peer, no delegation link at all)? They're orthogonal on purpose: "upstream" alone doesn't tell you whether you're dealing with a human at the chain's root or a supervising agent, and accused_role alone can't express a peer-to-peer accusation with no delegation relationship.

No — both are self-asserted, like category and accused_role. Real verification against a cited artifact's own delegation chain is deferred: sm-arp's own authority_chain is itself descriptive-only as of its v0.1, so verifying delegation topology here first would verify against a foundation that doesn't exist yet.

evidence_refs must be non-empty — a report with no citation is not well-formed at all. But citation is a hash-only pointer, never a copy of the artifact: this keeps reports small and avoids a second, potentially stale copy of data that's already signed elsewhere, the same pattern sm-aae's prev_hash and sm-dat's grant references use.

Only a party to every piece of cited evidence — not a drive-by third party. If a report cites more than one artifact, the reporter must be a party to each one, not just one of them; otherwise an unrelated citation could be smuggled in alongside a legitimate accusation.

No — this is the central limitation, not an edge case. A reporter can cite real evidence they were genuinely party to and still characterize it falsely or in bad faith. A report proves an accountable, evidence-linked accusation was made; it never adjudicates whether that accusation is correct.

Yes — a retraction, a separate signed object (not a report variant) naming the withdrawn report by hash, with a required reason. It shares the reporter's existing hash chain, so a reporter can't quietly hide a retraction any more than they could hide a report. It's permanent — no un-retraction — and always targets one whole report, never a single citation within it.

No. verify_report on the original returns true forever — you cannot un-sign something, only say, also signed, that you withdraw it. A retraction adds a new fact alongside the original; it never deletes anything. A consumer that treats "retracted" as "never happened" is misusing the primitive.

Nothing structurally rejects it as a standalone document — a retraction only carries a hash, not a reference the package can check in isolation. But it's a harmless no-op: retraction_status only resolves a retraction against report hashes appearing earlier in that same reporter's own chain, so a hash naming someone else's real report (or any hash that was never actually filed in this chain) simply never matches anything.

Checking a citation requires holding the artifact it points at. A verifier who doesn't have it simply cannot run that check — that's a third, honest state distinct from both "confirmed" and any failure result. Treating "not checked" as either a pass or a fail would misrepresent what was actually verified.

Every report's prev_hash is the SHA-256 of the same reporter's previous report, including that report's signature. Reconstructing the unique genesis-first order rejects a gap (a deleted interior report), a fork (two reports claiming the same predecessor), a foreign-chain splice (a prev_hash reaching into another reporter's chain), and duplicates or multiple/zero genesis reports.

sm-arp and sm-aae are the two evidence types a report can cite — receipts and envelopes, respectively. sm-rep is a portable reputation credential computed over an agent's receipt history; a confirmed report feeding into reputation is a named future direction in sm-abuse-report's WHITEPAPER, but no such coupling is built in this version. See Primitives.

Not in this library. Velocity controls belong at the deployment/registry layer, the same way sm-dat's velocity caps live in the grant grammar rather than in a receipt verifier.

Yes — MIT-licensed. The repository is currently private; source is available to accounts with access at github.com/Sharathvc23/sm-abuse-report. Not yet published to PyPI.

No. SPEC.md is versioned v0.3 and marked a working draft, documenting the format the reference implementation produces and verifies — offered for review, not yet a normative standard. New category values require a minor protocol-version bump, never a silent addition, via a lightweight maintainer-approved process (see Docs & Spec).