NeuroCognica

Security and Provenance

Cryptographic audit trails for every 3D artifact — the enterprise headline feature of Chronos-Sophia.

The Core Guarantee

Every rendered artifact in Chronos-Sophia can be traced to the exact prompt, seed, scene plan, and policy decisions that produced it. This is not metadata attached after the fact — it is a cryptographic chain of evidence sealed at the moment of creation.

What you can prove: - The exact natural-language prompt that initiated generation - The random seed and generation parameters - The validated scene plan (S³V structured schema) that was dispatched - The policy decisions made by the governance engine before render - The hash of the output file, recorded at seal time

How you verify:

"%ProgramFiles%\ChronoSophia\target\release\chronos.exe" dreamer proof render --render-dir C:\chronos\renders\<artifact-id>

This re-verifies the hash chain and confirms no tampering has occurred.

Architecture

The Provenance Ledger

Every consequential operation is recorded in a BLAKE3 hash-chained, append-only event log stored in RocksDB:

Event 0: Genesis / initialization
  ↓ (hash of Event 0 incorporated into Event 1)
Event 1: User prompt received
  ↓
Event 2: Plan synthesized and validated
  ↓
Event 3: Governance check (capability gate, policy verification)
  ↓
Event 4: Render dispatched
  ↓
Event 5: Render completed, output hash sealed

Key properties: - Append-only: No update or delete paths in the API - Hash-chained: Each event's hash includes the previous event's hash - Tamper-evident: Any post-hoc modification breaks the chain verification - Local: Stored on your machine, not in a cloud service

The Five Validation Gates

Before any command reaches Blender, the plan compiler (chronos_conductor/) validates through:

1. Schema gate: Valid JSON conforming to S³V structured scene schema
2. Vocabulary gate: Only allowed geometry terms and object classes
3. Spatial gate: Collision, support, and containment checks
4. Physical gate: Dimension and material plausibility
5. Policy gate: Authority verification, rate limits, capability bounds

Free-form LLM text never reaches the renderer. Only validated, typed commands from a closed vocabulary are dispatched.

The Session Capability Gate (CBIG)

The Context-Bound Integrity Gate (chronos_sentinel/src/cbig.rs) provides defense-in-depth:

• Per-session capability token binding the run to:
• An explicit command allowlist
• A set of authorized code-template hashes (BLAKE3 of script bodies)
• An expiry window

• MAC'd under a session-derived key

• Fail-closed rejection: Out-of-plan commands, expired tokens, or unregistered scripts are rejected before wire send and sealed as cbig_rejected events.

• Proven protection: Red-team drift tests have demonstrated CBIG blocking unauthorized command injection.

Governance Engine Modes

The policy-enforcement engine runs in two modes:

Set via: --sentinel-mode shadow|enforce

Verification Commands

Verify a Render

"%ProgramFiles%\ChronoSophia\target\release\chronos.exe" dreamer proof render --render-dir <path>

Checks: - Output file exists and hash matches sealed record - Provenance chain is intact - All intermediate events are present

Verify an Asset

"%ProgramFiles%\ChronoSophia\target\release\chronos.exe" dreamer proof asset --asset-id <id>

Verify the Chain

"%ProgramFiles%\ChronoSophia\target\release\chronos.exe" dreamer proof decide --render-dir <path>

Outputs a human-readable tribunal decision on artifact validity.

Security Model

Local-First Sovereignty

The table below describes the current default creative pipeline. It should not be read as a blanket promise that no future Windows release surfaces will ever touch the network. Update-channel and telemetry policy work are documented separately under docs/windows/.

Authority and Authentication

The governance engine implements: - BLAKE3 policy digests: Immutable policy fingerprinting - Ed25519 signature verification: Actor-to-key identity registry - Windowed nonce replay protection: Prevents command replay attacks - Fail-closed authorization: Missing or invalid authority blocks dispatch

Code Integrity

• Script templates are registered by BLAKE3 hash
• Unregistered script hashes are rejected by CBIG
• The BlenderMCP addon is vendored in-repo, not fetched from external sources

Compliance Applications

Errors and Omissions (E&O) Coverage

The provenance ledger provides: - Chain of custody: Every artifact traceable to its origin - Non-repudiation: Sealed records cannot be retroactively modified - Audit-ready evidence: Hash verification is deterministic and reproducible

This maps to ISO endorsements CG 40 47 / CG 40 48 / CG 35 08 contexts for media liability and professional liability coverage.

Internal Audit

For organizations generating 3D assets: - Prove the source of any rendered object - Verify policy compliance at generation time - Detect anomalous generation patterns via chain analysis

Legal Evidence

The append-only, hash-chained structure is designed to: - Resist tampering by operators or administrators - Provide cryptographic verification independent of the application - Support third-party audit with read-only access to the ledger

Threat Model and Mitigations

Technical Verification

The proof tribunal commands use the same verification logic as the runtime system:

// Pseudocode of verification logicn verify_chain(root: &Hash, events: &[Event]) -> Result<(), Error> {
    for (i, event) in events.iter().enumerate() {
        let expected = if i == 0 { root } else { &events[i-1].hash };
        if event.previous_hash != *expected {
            return Err(ChainBreak);
        }
        if blake3_hash(event.serialized()) != event.hash {
            return Err(HashMismatch);
        }
    }
    Ok(())
}

All verification is deterministic and can be performed offline given the ledger files.

Comparison with Alternatives

Limitations and Honest Assessment

Current: - CBIG is opt-in (not default-on) via environment variable - Visual-acceptance gate (automatic quality rejection) not yet built - Animation pipeline exists but not at release quality

Design limitations: - Provenance proves what system generated this artifact, not the artistic intent behind the prompt - Hash verification confirms this file matches the sealed record, not this is objectively good art - Local-only operation means no cloud backup — you manage your own data

Further Reading

• SENTINEL_SECURITY_PROTOCOL.md — What the governance prevents, what it cannot prevent, and the measured performance of the content-safety gate, including open findings. Start here for the honest limits
• PRODUCT_OVERVIEW.md — System capabilities and positioning
• FAQ.md — Common operational questions

Glossary