Why tamper evidence matters
Traditional logs are useful, but they often live inside systems that administrators can modify, rotate, delete, or separate from the decision context. For high-consequence actions, “a row exists in a log table” may not be enough.
SignalFang treats the decision as a proof object. If the evidence is altered after the fact, the verification path should fail or show a warning.
What can be sealed
A SignalFang receipt can seal the important parts of a decision without storing the protected payload itself.
- Identity reference or operator reference
- Source system and action type
- Request hash or target object reference
- Timestamp and decision state
- Context fields, reason codes, confidence values, or degraded-mode state
- Integrity metadata used for later verification
Verification goals
A verification flow should answer: is the receipt structurally valid, does the hash match the stored context, does the record fit the expected chain, was it replayed, and does the final integrity state pass?
The practical result
The goal is simple: when someone asks “who approved this and did the proof change later,” the answer should not depend on screenshots, tribal memory, or a fragile pile of disconnected logs.
Quick answers
What does tamper-evident mean?
It means the record is designed so later changes are detectable during verification.
Is tamper-evident the same as tamper-proof?
No. Tamper-evident does not mean nobody can attempt changes. It means changes should become visible when the proof is checked.
Does this replace logs?
No. SignalFang complements logs by creating a focused decision receipt around the approval event.
Need proof around a workflow?
SignalFang is exploring pilot workflows where signed decision receipts, payload-safe evidence, and local verification matter.