The direct answer
Bind the verification result to its accepted signer, protocol context, exact captured messages and declared coverage before using it as audit evidence. A valid signature is insufficient when covered messages are missing or the collection scope is unknown. Even a completely verified selected set does not establish every application action or the end of a continuing log.
Review a bounded evidence set, not an integrity badge
An operator reviewing an AI draft workflow receives two audit messages and a result labeled “signature valid.” The useful question is which exact records that result covers. One pleasant badge cannot explain a missing record, a duplicate arrival or evidence mixed from different reporting contexts.
This historical-protocol worksheet selects offline review of one bounded captured set, one independently accepted signer, one reboot session and one group whose messages are all intended for the selected collector. It excludes session resets, counter wrap, partial routing and unsupported overlap handling. Actual evidence for those restrictions remains required.
All examples and eight cards are PROPOSED_UNRUN. No log message, signature, key, digest, verifier, parser, collector, fixture or model operation was constructed or executed. The labels below are paper references, not protocol encodings or cryptographic results.
Keep the protocol context attached
RFC 5848, a May 2010 Standards Track document, associates whole-message hashes with Signature Blocks. Offline review separates signer identity—HOSTNAME, APP-NAME and PROCID—from reboot session and group. SG selects the grouping mode; SPRI is interpreted under that mode. FMN, CNT and ordered hashes describe group-relative message positions. The signer can differ from the original message producer; GBC counts blocks, not business events.
Our proposed receipt retains the complete supported interpretation, not a number stripped from its context. A remembered position from another group cannot silently become a record in this set. A business correlation identifier remains a separate application association; it is not replaced by a protocol counter.
The complete compliant verifier and trust mapping are prerequisites. This worksheet supplies no signature algorithm choice, certificate handling, field decoder or substitute hash-chain design. Historical documentation is not a recommendation that an available implementation is suitable for a current deployment.
Preserve the representation being verified
RFC 5424, a March 2009 Standards Track document, defines the syslog message as header, structured data and optional message content, separately from transport. It specifies no storage format. Its PROCID has implementation-dependent meaning and is not a reliable process-restart identifier.
Keep the captured representation and the operator’s display separate. A shortened, normalized or re-rendered view may help a person read, but our receipt cannot substitute it for the independently established verification input. The adapter must establish exact message boundaries and preservation under its supported contract; neither a file extension nor this article implements that adapter.
Do not infer an actual process, model identity or event truth from familiar header text. Independent signer policy, message-origin association and application evidence still need their own review. Store only permitted minimized records; signing does not supply permission to retain sensitive content.
Work through one useful two-message receipt
Invent receipt R-A for teaching records M-A and M-B. A complete supported verification result associates them with positions 41 and 42 in the selected context. Their application meanings are “draft proposed” and “review required.” No message bytes or actual event records exist for this exercise.
| Evidence field | Required decision |
|---|---|
| Trust | Accepted signer and protected trust-policy revision, not self-asserted identity. |
| Context | One fully interpreted group/session and supported bounded range. |
| Representation | Exact admitted capture for M-A and M-B. |
| Association | Complete verifier result binds those records to the declared positions. |
| Collection scope | Independent evidence every selected-group message is intended for this collector. |
| Exceptions | Missing, repeated, mismatched and order observations retained separately. |
| Application meaning | Separate decision/effect evidence and unresolved reporting limits. |
The useful positive admits only R-A’s supported signed-message association for protected review. It does not authorize publication, settle a business operation or certify the application’s event generator. If either record is missing, preserve the partial evidence without presenting R-A as complete.
Distinguish a gap from an unsupported coverage assumption
RFC 5848’s offline review identifies authenticated-message gaps when all messages of the group go to the same collector. Its partial-routing discussion limits that inference. It also addresses duplicates and message order; message alteration or truncation breaks verification.
For this worksheet, a covered absent M-B fails the declared two-record requirement. If the collector’s intended population is unknown, the cause and coverage stay unknown too. Do not invent “network loss” or assume the absent record was irrelevant. Do not reconstruct its contents from a model’s explanation.
Likewise, receiving M-B before M-A is an arrival observation. Retain the supported protocol association alongside it without converting either into a universal chronology of application actions. Unknown clock quality or omitted instrumentation cannot be repaired by sorting a display.
Walk eight inert coverage cards
| Condition | Proposed disposition |
|---|---|
| 1. R-A is complete and every trust, context, capture and coverage prerequisite holds | Conditionally admit the bounded association only. |
| 2. M-A differs from the admitted verification input | Hold the mismatch; readable similarity is insufficient. |
| 3. Covered M-B is absent | Mark the selected set incomplete; retain collection-scope uncertainty. |
| 4. M-A arrives again | Record repetition separately; infer no additional business effect. |
| 5. M-B arrives before M-A | Preserve arrival and supported position evidence separately. |
| 6. Another context contributes the same position number | Reject unsupported cross-context substitution. |
| 7. Signature validity is reported but signer authority or complete result is unknown | Withhold accepted-evidence status. |
| 8. R-A verifies but later records or an action were never evidenced | No final-log or complete-execution claim. |
Leave missing prerequisites visible
Actual producer and signer association, protected trust policy, current cryptographic suitability, compliant verifier, exact capture, complete context, collection topology, bounded handling and immutable handoff are unimplemented and unknown. They block a real positive. This is no storage, confidentiality, reliable-delivery, stream-termination or nonrepudiation certificate.
The application audit guide still separates authorization from effects, and the framing guide still controls record construction. Boundary remains prelaunch with planned request-path checks, not a shipped signed-audit verifier. Its separate mock-policy evidence validates none of these proposed cards.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.