Reputation and Derived Signals

Reputation is an optional consumer of verified audit data. It is not part of the authoritative ledger, and an Audit Assurance Profile is not a reputation score.

Safe derivation pipeline

A derived signal should identify:

• the ledger epochs and sequence ranges used;
• the verification policy and report digest;
• projection and model versions;
• relevant gaps, redactions, unavailable evidence, and observation freshness;
• calculation time, expiry, and confidence;
• an appeal or correction path where applicable.

Appropriate inputs

Depending on policy and purpose, inputs can include verified delegation status, authorization outcomes, proof verification results, revocation use, repeated denied actions, source gaps, or audit-system health. Normalize for opportunity and context; raw event counts often punish high-volume agents and reward agents with missing telemetry.

Prohibited shortcuts

• Do not write a calculated score back into historical entries.
• Do not interpret a missing event as a successful action.
• Do not equate AAP-4 with trustworthy behavior; it means conflicting ledger views are more detectable.
• Do not accept a producer-supplied reputation or assurance label as authoritative.
• Do not conceal gaps, redactions, or policy exclusions from downstream consumers.
• Do not use global identifiers when pairwise or committed identifiers satisfy the purpose.

Registry publication

A registry may publish reputation signals or conformance badges when it also publishes their meaning, provenance, expiry, and verification method. Consumers must be able to distinguish protocol conformance, audit assurance, operational health, and behavioral reputation; those are separate claims.

Recompute signals when source data, verification policy, key-revocation status, projection logic, or model version changes. Preserve prior outputs as versioned derived artifacts rather than mutating ledger evidence.