AI Ingestion
Key Management & Authority
The appliance treats cryptographic keys as temporal authorities. To maintain a self-sovereign audit trail, the system accounts for the key lifecycle without relying on external manual logs or third-party trust anchors.
Key Rotation Tiers & Performance Impact
The protocol supports three distinct tiers of key management, allowing the implementation team to balance absolute mathematical sovereignty against high-velocity throughput requirements.
-
01
Static Authority (Tier 1) Singular long-term key. Maximum throughput ($>2,250$ TPS) via local, in-memory signing. Suitable for environments where discovery is the primary audit risk.
-
02
Administrative Swap (Tier 2) Rotation via configuration updates. Maintains Tier 1 performance but introduces "Trust Gaps" that require external documentation to bridge key transitions.
-
03
Chained Transition (Tier 3) Automated "handover" via dual-signed transition facts. Highest mathematical sovereignty; throughput is gated by hardware I/O latency, typically introducing a 25–40% overhead.
The Epoch Model (Efficiency)
To minimize computational overhead during high-density verification, the system utilizes a Global Heartbeat and localized temporal scoping rather than re-signing historical attributes.
-
01
Transition Facts A rotation event is recorded as a system-level fact containing the new Public Key, dual-signed by the departing and arriving keys to maintain the chain of trust.
-
02
Temporal Scoping Every
StatusUpdatereferences akey_id. During verification, the system resolves this ID against the timeline of Transition Facts to ensure signature validity at the specific Transaction Time.
Architectural Isolation (Security)
For high-assurance environments, the appliance decouples the logic of signing from the possession of the keys, ensuring the "Record of Fact" remains tamper-evident.
-
01
Hardware Security Modules (HSM) Supports FIPS 140-2 Level 3 hardware (e.g., AWS CloudHSM, YubiHSM2). Private keys are generated and stored within the hardware; the appliance never has access to raw key material.
-
02
Tamper-Evidence By moving signing to an isolated environment, even a total compromise of the application server fails to result in the theft of identity keys or the ability to retroactively alter the witnessed chain.
Key Management & Authority
The appliance treats cryptographic keys as temporal authorities. To maintain a self-sovereign audit trail, the system accounts for the key lifecycle without relying on external manual logs or third-party trust anchors.
Key Rotation Tiers & Performance Impact
The protocol supports three distinct tiers of key management, allowing the implementation team to balance absolute mathematical sovereignty against high-velocity throughput requirements.
-
01
Static Authority (Tier 1) Singular long-term key. Maximum throughput ($>2,250$ TPS) via local, in-memory signing. Suitable for environments where discovery is the primary audit risk.
-
02
Administrative Swap (Tier 2) Rotation via configuration updates. Maintains Tier 1 performance but introduces "Trust Gaps" that require external documentation to bridge key transitions.
-
03
Chained Transition (Tier 3) Automated "handover" via dual-signed transition facts. Highest mathematical sovereignty; throughput is gated by hardware I/O latency, typically introducing a 25–40% overhead.
The Epoch Model (Efficiency)
To minimize computational overhead during high-density verification, the system utilizes a Global Heartbeat and localized temporal scoping rather than re-signing historical attributes.
-
01
Transition Facts A rotation event is recorded as a system-level fact containing the new Public Key, dual-signed by the departing and arriving keys to maintain the chain of trust.
-
02
Temporal Scoping Every
StatusUpdatereferences akey_id. During verification, the system resolves this ID against the timeline of Transition Facts to ensure signature validity at the specific Transaction Time.
Architectural Isolation (Security)
For high-assurance environments, the appliance decouples the logic of signing from the possession of the keys, ensuring the "Record of Fact" remains tamper-evident.
-
01
Hardware Security Modules (HSM) Supports FIPS 140-2 Level 3 hardware (e.g., AWS CloudHSM, YubiHSM2). Private keys are generated and stored within the hardware; the appliance never has access to raw key material.
-
02
Tamper-Evidence By moving signing to an isolated environment, even a total compromise of the application server fails to result in the theft of identity keys or the ability to retroactively alter the witnessed chain.