Three guarantees you don't have to take Verdra's word for: (1) the record is signed by your company's own keys, not Verdra's, so no one at Verdra can sign anything on your behalf; (2) the record lives in storage you own and lock down (an S3 bucket with retention rules, for example), so Verdra has no way to alter or delete it; (3) a third-party timestamping service stamps each record at the moment of capture, so neither Verdra nor you can backdate it after the fact (RFC 3161 timestamping is deferred in V0.1 and disclosed in each package as a forward commitment under Rules P.5).
The rest of this page is the technical version of those three guarantees, written for your security team.
1. Threat model
The system protects against four families of threat:
- Post-hoc tampering with the record after the disputed action.
- Reconstruction of state at the time of action from inferior logs.
- Repudiation by either party of what the agent was configured to do.
- Vendor capture: any architecture in which Verdra has the technical ability to alter the record unilaterally.
The integrity model places Verdra outside the trust boundary for record contents. The customer's keys sign; the customer's storage holds; an external timestamp authority countersigns at V1.0 (deferred in V0.1 as a forward commitment under Rules P.5); the schema and rulebook are public.
2. Capture flow
3. Integrity primitives
4. Behavior stratum: self-report vs. re-derived
S(c) Behavior captures what the agent would have done at decision time. Two collection modes are supported, and the mode used is recorded in the package itself:
- Self-reported (default for streaming capture). The runtime emits a decision log at dispatch: tool calls considered, latency, the chosen action, and a short rationale token. Cheap, fast, and the agent runtime is the source. This mode is appropriate where the dispute is about what was done, not what would have been done.
- Externally re-derived (counterfactual mode). Verdra Record re-runs the captured configuration (S(b)) against the captured prompt N times in an isolated sandbox to compute a modal-action distribution and sharpness score. Re-derivation is independent of the live runtime and resistant to a compromised agent. Appropriate for disputes that turn on whether the chosen action was within policy.
Both modes carry the BLAKE3 root forward; an adjudicator can see which mode produced the S(c) row and weight it accordingly.
5. What Verdra cannot do
The architecture is designed so these claims hold without trusting Verdra in good faith:
- Verdra cannot read Evidence Package contents in normal operation. Packages live in customer storage. Verdra reads a package only when the customer's authorization scopes a specific dispute or audit.
- Verdra cannot sign on the customer's behalf. Signing keys live in the customer's KMS; Verdra has no derivation path.
- Verdra cannot backdate. RFC 3161 timestamps are issued by an external TSA, with V0.1 packages deferring the TSA call as a forward commitment under Rules P.5; the timestamp chain is verifiable end-to-end without Verdra in the loop once the commitment closes.
- Verdra cannot delete a package. Storage is customer-controlled; retention is a customer policy.
- Verdra cannot mutate the schema retroactively. Schema versions are pinned at capture time and re-deriving any prior version is deterministic.
6. Disclosure and engagement model
Production-stage deployments include a Data Processing Agreement scoping the customer/Verdra role under GDPR / Quebec Law 25 / CCPA, key-management responsibilities, retention defaults, and incident-notification windows. The DPA is shared at engagement; request the security packet for security-team review.
7. Roadmap
This page is a preview-stage description of Verdra Record's intended architecture. Specific control implementation, KMS integration patterns, and audit evidence are scoped per engagement.