Technical Specification
Immutable Audit Boundary
Formal specification of audit artifact format, signing scheme, and verification procedure.
Overview
The V2 Engine produces a cryptographically signed audit artifact for each execution. These artifacts create an immutable record of what was evaluated, when, and with what result.
This specification defines the artifact structure, serialization format, signing algorithm, and verification procedure.
Version: 1.0
Status: Current
Last Updated: February 2026
Artifact Structure
Each audit artifact is a JSON document containing:
{
"version": "1.0",
"timestamp": "2026-02-04T19:23:15.000Z",
"engine_version": "2.1.0",
"ruleset_version": "2024-Q4",
"ruleset_hash": "sha256:e5f6g7h8...",
"input_hash": "sha256:a1b2c3d4...",
"output_hash": "sha256:i9j0k1l2...",
"environment": {
"deployment_id": "prod-01",
"runtime": "node-20.11.0",
"platform": "linux-x64"
},
"execution": {
"duration_ms": 245,
"rules_evaluated": 1247,
"rules_triggered": 3
},
"signature": {
"algorithm": "RSA-SHA256",
"key_id": "deploy-key-001",
"value": "base64-encoded-signature"
}
}Field Definitions
version
Artifact format version. Current: "1.0"
timestamp
ISO 8601 UTC timestamp of execution start
engine_version
Semantic version of the V2 Engine binary
ruleset_version
Version identifier of the rule set
ruleset_hash
SHA-256 hash of the rule set used for execution
input_hash
SHA-256 hash of the canonical input data
output_hash
SHA-256 hash of the execution output
environment
Deployment environment metadata
execution
Execution statistics (duration, rules evaluated, rules triggered)
signature
Cryptographic signature of the artifact
Canonical Serialization
To ensure reproducible signatures, the artifact must be serialized in a deterministic format before signing.
Rules
- Field order: Fields must appear in alphabetical order
- Whitespace: No unnecessary whitespace or line breaks
- Unicode: UTF-8 encoding without BOM
- Numbers: No leading zeros or trailing decimals
- Signature exclusion: The signature field is excluded from the canonical representation
Example
{"engine_version":"2.1.0","environment":{"deployment_id":"prod-01","platform":"linux-x64","runtime":"node-20.11.0"},"execution":{"duration_ms":245,"rules_evaluated":1247,"rules_triggered":3},"input_hash":"sha256:a1b2c3d4...","output_hash":"sha256:i9j0k1l2...","ruleset_hash":"sha256:e5f6g7h8...","ruleset_version":"2024-Q4","timestamp":"2026-02-04T19:23:15.000Z","version":"1.0"}Signing Algorithm
Artifacts are signed using RSA-4096 with SHA-256 (RSASSA-PKCS1-v1_5).
Process
- 1. Serialize: Generate canonical JSON representation (excluding signature field)
- 2. Hash: Compute SHA-256 hash of the canonical representation
- 3. Sign: Sign the hash using RSA-4096 private key
- 4. Encode: Base64-encode the signature
- 5. Embed: Add signature field to the artifact
Key Management
Each deployment uses a unique key pair for signing audit artifacts. The private key must be:
- Generated within the deployment environment (never transmitted)
- Stored securely (HSM or encrypted key store)
- Access-controlled (least privilege)
- Rotated periodically (recommended: annually)
The public key must be:
- Published in a trusted location
- Associated with a key identifier (key_id)
- Protected from unauthorized modification
Verification Procedure
To verify an audit artifact:
Steps
- 1. Parse: Parse the artifact as JSON
- 2. Extract signature: Extract the signature.value and signature.key_id fields
- 3. Retrieve public key: Fetch the public key corresponding to key_id
- 4. Reconstruct canonical form: Serialize the artifact without the signature field
- 5. Verify signature: Verify the signature using the public key and RSA-SHA256
- 6. Verify hashes: Optionally verify input_hash and output_hash match provided data
Example (Pseudocode)
// Load artifact
artifact = JSON.parse(artifact_json)
// Extract signature
signature = base64_decode(artifact.signature.value)
key_id = artifact.signature.key_id
// Retrieve public key
public_key = get_public_key(key_id)
// Reconstruct canonical form
canonical = canonical_serialize(artifact, exclude: ["signature"])
// Verify signature
is_valid = rsa_verify(
public_key: public_key,
message: canonical,
signature: signature,
algorithm: "RSA-SHA256"
)
if (!is_valid) {
throw "Signature verification failed"
}
// Optionally verify hashes
if (input_data) {
expected_hash = sha256(canonical_serialize(input_data))
if (artifact.input_hash != expected_hash) {
throw "Input hash mismatch"
}
}
if (output_data) {
expected_hash = sha256(canonical_serialize(output_data))
if (artifact.output_hash != expected_hash) {
throw "Output hash mismatch"
}
}Failure Modes
Signature Verification Failure
Cause: Artifact has been tampered with or corrupted after signing.
Action:
- Reject the artifact
- Investigate the source of tampering
- Check audit log storage integrity
- Report to security team
Input Hash Mismatch
Cause: The provided input data does not match the execution record.
Action:
- Verify input data source
- Check for data corruption
- Ensure canonical serialization is correct
Output Hash Mismatch
Cause: Output has been modified post-execution.
Action:
- Reject the output
- Investigate modification source
- Re-execute if necessary
Missing Key ID
Cause: Signing key is not available for verification.
Action:
- Check key registry
- Verify key_id is correct
- Restore key from backup if rotated
Sample Artifact (Redacted)
Below is a complete audit artifact with redacted sensitive values:
{
"version": "1.0",
"timestamp": "2026-02-04T14:23:45.123Z",
"engine_version": "2.1.0",
"ruleset_version": "2024-Q4",
"ruleset_hash": "sha256:7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069",
"input_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"output_hash": "sha256:2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae",
"environment": {
"deployment_id": "prod-us-east-1",
"runtime": "node-20.11.0",
"platform": "linux-x64"
},
"execution": {
"duration_ms": 312,
"rules_evaluated": 1543,
"rules_triggered": 7
},
"signature": {
"algorithm": "RSA-SHA256",
"key_id": "deploy-key-2026-01",
"value": "rBMYcVQ2J...{redacted}...xKp2Nw=="
}
}Implementation Notes
Storage Recommendations
- Store artifacts in append-only storage (prevent modification)
- Use immutable storage backends (e.g., WORM, object storage with versioning)
- Implement retention policies aligned with regulatory requirements
- Backup artifacts to separate, tamper-resistant location
Performance Considerations
- Signing adds ~5-10ms overhead per execution
- Verification is faster than signing (~2-5ms)
- Consider batch verification for large audit reviews
Compliance Considerations
This artifact structure supports:
- HIPAA audit trail requirements (45 CFR § 164.312(b))
- FDA 21 CFR Part 11 (electronic records and signatures)
- SOC 2 Type II (audit logging and integrity controls)