Kinetic Trust Protocol (KTP) - Flight Recorder Specification¶
This document specifies the Flight Recorder system for the Kinetic Trust Protocol (KTP). The Flight Recorder provides immutable audit logging of all authorization decisions, enabling forensic analysis, compliance verification, and system learning.
The specification covers Decision Geometry (the multi-dimensional record of each decision), storage requirements, query interfaces, retention policies, and integration with external audit systems.
Introduction¶
The Flight Recorder is the memory of a KTP system. Every decision, every state change, every veto is recorded with full context, creating an immutable history that can be queried, analyzed, and used for both forensic investigation and system improvement.
The Invisible Success Problem¶
Traditional security systems suffer from an invisible success problem: when an attack is prevented, there is no incident to investigate. The prevented disaster is invisible, making it difficult to:
- Prove that security controls are working
- Learn from near-misses
- Justify security investments
- Distinguish luck from competence
The Flight Recorder solves this by recording every Silent Veto with the same detail as an allowed action. A prevented attack is visible in the record:
"At 14:32:07, Agent X attempted action Y with risk 85.
E_trust was 42 due to elevated adversarial_pressure (0.78) from active
attack indicators. Silent Veto triggered. Action denied.
If this action had been permitted, blast radius would have
included 47 downstream services."
The disaster that didn't happen is now visible, auditable, and valuable for learning.
Flight Recorder Philosophy¶
The Flight Recorder follows these principles:
-
Record Everything: Every authorization decision, not just denials or anomalies. The baseline is as important as the exceptions.
-
Context Over Outcome: The derived decision verb is one bit's worth of reading. The context (why, what was the environment, what would have happened) is where the value lies.
-
Immutability: Once written, records cannot be altered or deleted. This is essential for legal defensibility and forensic integrity.
-
Queryability: Data that can't be queried is data that won't be used. The Flight Recorder must support rich queries for forensic analysis.
-
Forward Secrecy: Records should be usable for learning without exposing sensitive operational details.
Requirements Language¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].
Terminology¶
Attestation: A cryptographically signed statement about an agent's behavior, issued by the Trust Oracle after successful transaction.
Decision Geometry: The multi-dimensional record of a single authorization decision, including agent context, environmental state, action details, and outcome.
Flight Recorder: The immutable audit log system that records all KTP decisions and state changes.
Forensic Reconstruction: The process of recreating the exact conditions that led to a specific decision, using Flight Recorder data.
Hot Storage: Fast, frequently accessed storage for recent records (hours to days).
Cold Storage: Archival storage for historical records (months to years).
Record Chain: A sequence of records cryptographically linked via hash pointers, ensuring tamper detection.
Warm Storage: Intermediate storage for less frequently accessed records (days to months).
Decision Geometry¶
Every authorization decision is recorded as a Decision Geometry - a multi-dimensional snapshot that captures not just what happened, but why it happened and what would have happened under different conditions.
Core Components¶
A Decision Geometry record contains:
{
"record_id": "dr-uuid-12345",
"record_type": "authorization_decision",
"timestamp": "2025-11-25T14:32:07.123Z",
"chain": {
"previous_hash": "sha256:abc123...",
"sequence_number": 1847392
},
"agent": { ... }, // Agent context
"environment": { ... }, // Environmental snapshot
"action": { ... }, // Requested action
"decision": { ... }, // Outcome and reasoning
"counterfactual": { ... } // What-if analysis
}
Record Identification¶
record_id: Globally unique identifier for this record. Format: "dr-" + UUIDv4 for decision records.
record_type: Type of record. One of:
- authorization_decision
- trust_score_change
- tier_transition
- soul_veto
- attestation
- system_event
timestamp: ISO 8601 timestamp with millisecond precision. MUST be in UTC.
Chain Integrity¶
previous_hash: SHA-256 hash of the immediately preceding record. Creates tamper-evident chain.
sequence_number: Monotonically increasing sequence number. Gaps indicate potential tampering or data loss.
These are Flight Recorder chain fields. They are not the v3 trajectory record_hash contract in specifications/trajectory-signatures.md, which hashes the canonical completed trajectory envelope excluding only its own record_hash. Implementations MUST keep the two record types and their hash preimages distinct.
Environmental Snapshot¶
The environmental snapshot captures the complete Risk Factor input state at decision time:
"environment": {
"risk_factors": {
"evidence_density": 0.45,
"trust_trend": 0.78,
"adversarial_pressure": 0.82,
"moment_criticality": 0.30,
"update_resistance": 0.25,
"attestation_coverage": 0.15
},
"r": 0.523,
"soul": {
"soul": 0,
"constraint_type": null
},
"sensor_health": {
"evidence_density": { "feeds_active": 4, "feeds_total": 5 },
"trust_trend": { "feeds_active": 3, "feeds_total": 3 },
"degraded_inputs": ["evidence_density"]
},
"normalization_profile": "prod-standard@3",
"trust_oracle": {
"oracle_id": "oracle-east-1",
"quorum": "3-of-5",
"latency_ms": 3
},
"zone": {
"zone_id": "zone-blue-prod-01",
"zone_type": "blue",
"federation": ["zone-blue-prod-02", "zone-cyan-staging"]
}
}
sensor_health carries the normalization-profile identifier, \
This snapshot enables forensic reconstruction: given the exact environmental conditions, we can replay the decision logic and verify that the correct outcome was reached.
The legacy trust_oracle.quorum value in this example describes the cryptographic signing threshold. It MUST NOT be interpreted as a consensus decision quorum or proof of agreement. For decisions relying on Oracle mesh state, the Flight Recorder MUST retain the applicable commit evidence, or an integrity-protected reference resolving to retained evidence, and its binding to the resulting standing or operation under specifications/oracle-consensus.md. The record MUST identify the installed configuration and membership epoch, protocol/version, view, phase or purpose, sequence/checkpoint position, predecessor/state, and operation or control-payload digest required by that protocol. Canonical encodings and evidence formats are defined by the selected protocol. Evidence needed for reconstruction MUST remain available for the decision record's retention period; an unresolved reference is not evidence of consensus.
For a v3 trajectory transition, the retained evidence MUST distinguish the committed typed intent before Oracle signing from the independently anchored final record_hash afterward. The latter binds record_version, the exact completed signature envelope, commit_intent, agent, zone, chain, sequence, and predecessor and is required before authoritative append. Audit reconstruction MUST NOT replace the final-head evidence with a newly recomputed hash, an intent certificate, or another valid signature envelope. Migration evidence MUST retain the original legacy archive bytes or integrity-protected retained archive, its authenticated head, approved checkpoint and revalidated-state evidence, new-genesis binding, final-genesis anchor, and durable single-use succession/format-floor transition. Recording a candidate's assertion in the Flight Recorder does not independently authenticate it.
For operation-scoped readiness, retain the complete signed decision and assessment evidence, approved criteria and assessor/issuer authority, actual request and subject-state bindings, installed deployment/readiness profiles, readiness epoch, validity times, and relevant revocation or change evidence required by specifications/operational-readiness.md. A signed v3 trajectory carries the complete decision sidecar in its existing action.details.readiness object; it binds an already complete ordinary proof and introduces no top-level trajectory field or cyclic hash.
If no readiness decision was issued or required evidence was unavailable, log that absence and the denial reason; do not fabricate a passed assessment or a signed sidecar. An invalid candidate may be retained as rejected evidence with that status, never as proof of current readiness.
Records MUST distinguish historical PoR evidence from current readiness, successful assessment from a grant of permission, and authenticated correction of an invalid historical claim from mere inactivity. A heartbeat, renewed signature, or fresh ordinary proof MUST NOT be logged as fresh assessment evidence unless an actual assessment meeting the installed criteria occurred. A denied operation, expired readiness, or reassessment requirement MUST NOT silently subtract historical PoR. Review and recovery must be able to reconstruct which operation and exact subject configuration were assessed; an unresolvable evidence reference cannot establish readiness.
Agent Context¶
Agent context captures the identity and state of the requesting agent:
"agent": {
"agent_id": "agent:7gen:optimized:a1b2c3d4",
"lineage": "guarantor",
"generation": 7,
"sponsor": null,
"e_base": 87,
"e_trust": 42,
"de_dt": -2.3,
"sigma": 0.15,
"tier": "analyst",
"previous_tier": "operator",
"tier_duration_seconds": 847,
"trajectory_hash": "sha256:def456...",
"resilience_score": 0.82,
"session": {
"session_id": "sess-xyz789",
"session_start": "2025-11-25T13:00:00Z",
"actions_this_session": 1247,
"vetoes_this_session": 3
}
}
Key fields:
e_base: Agent's intrinsic capability (from Proof of Resilience)
e_trust: Effective Trust Score after environmental deflation
de_dt: Trust velocity (rate of change)
tier: Current Trust Tier
previous_tier: Tier before most recent transition (if recent)
trajectory_hash: Hash of agent's trajectory chain for verification
Decision Outcome¶
The decision outcome records what happened and why:
"decision": {
"supervision": "silent_veto",
"reason": "TRUST_INSUFFICIENT",
"tightened_constraints": {},
"evaluation": {
"soul_check": "pass",
"tier_check": "pass",
"zeroth_law_check": "fail",
"a": 85,
"e_trust": 42,
"gap": 43
},
"enforcement_point": {
"pep_id": "pep-api-gateway-east",
"pep_type": "api_gateway",
"latency_ms": 2
},
"notification": {
"agent_notified": true,
"response_code": 403,
"response_body_hash": "sha256:ghi789..."
}
}
Key fields:
supervision: the returned supervision level (stable, metacognitive, assisted, regulated, or silent_veto), per [KTP-CORE] Section 6.7 (Aggregation Algorithm)
tightened_constraints: the tighten-only constraint set on the result; present on every decision
margin: the Zeroth Law margin the supervision was derived from; MUST be present when margin calculation was reached and MUST be omitted when an earlier check stopped the evaluation, per [KTP-CORE] Section 6.7 (Aggregation Algorithm). The example above vetoes A > E_trust before division and therefore has no margin. An omitted margin MUST NOT be interpreted as zero.
reason: KTP error code when supervision is silent_veto
evaluation: Step-by-step evaluation trace
gap: Difference between A and E_trust (how far from threshold)
The decision verb (ALLOW, SHAPE, DEAUTOMATE, VETO) is derived from supervision and tightened_constraints per [KTP-CORE] Section 6.7 (Aggregation Algorithm) and is not stored; the record carries the result the verb is read from.
Counterfactual Analysis¶
The counterfactual section records what would have happened under different conditions:
"counterfactual": {
"if_allowed": {
"blast_radius": {
"services_affected": 47,
"users_affected": 12500,
"data_records_at_risk": 1847392
},
"reversibility": "partial",
"estimated_recovery_time_minutes": 45
},
"threshold_analysis": {
"e_trust_needed": 85,
"e_trust_actual": 42,
"r_needed_for_allow": 0.03,
"r_actual": 0.52,
"primary_contributor": "heat",
"heat_value": 0.82,
"heat_source": "waf_blocks_elevated"
}
}
This analysis is invaluable for:
- Understanding near-misses
- Quantifying prevented damage
- Identifying which Risk Factor input drove the decision
Record Types¶
Authorization Decision¶
The most common record type, created for every action request.
Schema:
{
"record_type": "authorization_decision",
"action": {
"method": "DELETE",
"resource": "/api/users/12345",
"action_class": "delete_permanent",
"action_risk": 85,
"parameters": {
"user_id": "12345",
"cascade": true
},
"source_ip": "10.0.1.45",
"request_id": "req-uuid-67890"
},
"agent": { ... },
"environment": { ... },
"decision": { ... },
"counterfactual": { ... }
}
Trust Score Change¶
Recorded when an agent's E_trust changes significantly (threshold configurable, default: change >= 5 points or crosses tier boundary).
Schema:
{
"record_type": "trust_score_change",
"agent_id": "agent:7gen:optimized:a1b2c3d4",
"change": {
"e_trust_before": 88,
"e_trust_after": 72,
"e_base": 95,
"r_before": 0.07,
"r_after": 0.24,
"delta": -16,
"velocity": -3.2
},
"cause": {
"primary_dimension": "heat",
"heat_before": 0.15,
"heat_after": 0.65,
"trigger_event": "waf_block_spike",
"trigger_details": {
"waf_blocks_per_minute": 5420,
"baseline": 200
}
},
"impact": {
"tier_before": "admin",
"tier_after": "operator",
"capabilities_lost": [
"write:production",
"execute:deployments",
"admin:config"
]
}
}
Tier Transition¶
Recorded when an agent crosses a Trust Tier boundary.
Schema:
{
"record_type": "tier_transition",
"agent_id": "agent:7gen:optimized:a1b2c3d4",
"transition": {
"from_tier": "operator",
"to_tier": "analyst",
"direction": "demotion",
"e_trust_at_transition": 68,
"threshold_crossed": 72
},
"duration_in_previous_tier_seconds": 14832,
"actions_in_previous_tier": 4721,
"vetoes_in_previous_tier": 12,
"agent_state": {
"in_flight_operations": 2,
"operations_cancelled": 1,
"graceful_degradation": true
}
}
Soul Veto¶
Recorded when a sovereignty constraint blocks an action. These records receive special handling due to their legal and cultural significance.
Schema:
{
"record_type": "soul_veto",
"agent_id": "agent:7gen:optimized:a1b2c3d4",
"action": {
"method": "POST",
"resource": "/api/data/export",
"action_class": "read_sensitive",
"action_risk": 40
},
"soul_constraint": {
"soul": 1,
"constraint_type": "tk_label",
"constraint_id": "TK-NC-001",
"constraint_name": "TK Non-Commercial",
"authority": "https://localcontexts.org/label/tk-nc/",
"community": "Example Indigenous Community",
"data_lineage": {
"data_id": "data-record-xyz",
"origin": "tribal-repository",
"collection_date": "2024-06-15",
"labels_applied": ["TK-NC", "TK-A"]
}
},
"note": {
"e_trust": 92,
"action_risk": 40,
"would_have_passed_zeroth_law": true,
"blocked_by_sovereignty": true
},
"remediation_provided": "Contact community data steward"
}
Soul Veto records MUST be:
- Retained for minimum 7 years (or as required by jurisdiction)
- Exportable for community review upon request
- Protected from modification by any party
Attestation¶
Recorded when the Trust Oracle issues an attestation of successful transaction, contributing to an agent's Proof of Resilience.
Schema:
{
"record_type": "attestation",
"agent_id": "agent:7gen:optimized:a1b2c3d4",
"attestation": {
"attestation_id": "att-uuid-12345",
"action_completed": "deploy_service_update",
"action_risk": 75,
"e_trust_at_action": 82,
"environment_state": "degraded",
"r_at_action": 0.14,
"resilience_contribution": 0.003
},
"signatures": {
"agent": "sig:agent:abc123...",
"oracle": "sig:oracle:def456...",
"timestamp_authority": "sig:tsa:ghi789..."
}
}
Immutability Requirements¶
Append-Only Storage¶
The Flight Recorder MUST preserve the exact bytes and integrity of signed records while they are retained. Records MUST NOT be silently edited, re-signed as if original, or deleted outside the approved retention and erasure process.
Personal evidence MUST follow specifications/privacy-evidence.md. New deployments handling such evidence MUST use the versioned minimal signed envelope and separately encrypted payload, or a separately reviewed equivalent with the same declared protections and verification limits. The normative reference format is schemas/privacy-evidence-envelope.json. Existing trajectory-v3 signatures and hashes remain unchanged inside protected evidence; the new outer storage signature is not a replacement for them.
Corrections and dispositions are new authenticated events. They MUST change the active evidence state and invalidate affected decisions without rewriting the old signed bytes. Erasure includes all applicable copies, keys, backups, derivatives and recipients; a notice alone is insufficient. Deletion MAY occur under an approved subject request or purpose-specific retention policy, with explicit scope, authority, and retained exceptions. Archiving MUST NOT restart retention or create a default permanent copy.
Infrastructure append-only controls SHOULD protect retained records against unauthorized mutation while permitting the declared lawful disposition process. Storage locks, replication and public anchors MUST be selected consistently with those obligations. Putting personal plaintext into an irretractable public ledger is not an erasure mechanism.
Cryptographic Chaining¶
Records MUST be cryptographically chained:
-
Each record includes hash of previous record
-
Hash algorithm: SHA-256 (minimum)
-
Chain creates tamper-evident sequence
-
Any modification breaks the chain
Chain structure:
Record N:
previous_hash: SHA256(Record N-1)
sequence_number: N
content: { ... }
record_hash: SHA256(previous_hash + sequence_number + content)
Chain verification:
For each record from oldest to newest:
1. Compute expected hash from content
2. Compare to stored hash
3. Verify previous_hash matches prior record's hash
4. Verify sequence numbers are contiguous
Tamper Detection¶
The Flight Recorder MUST detect tampering:
-
Periodic chain integrity verification (recommended: hourly)
-
Alert on any hash mismatch or sequence gap
-
Maintain chain anchors in external system (e.g., public blockchain timestamp)
-
Support third-party audit of chain integrity
Tamper detection response:
-
Immediately alert security team
-
Preserve evidence (snapshot of tampered section)
-
Isolate affected storage
-
Begin forensic investigation
-
Do NOT attempt to "fix" the chain
Storage Architecture¶
Hot Storage¶
Hot storage holds recent records for fast query access.
Characteristics:
- Retention: 24-72 hours
- Latency: < 10ms query response
- Technology: In-memory database, SSD-backed store
- Replication: Synchronous, multi-region
Use cases:
- Real-time dashboards
- Active incident investigation
- Live query by agents
Warm Storage¶
Warm storage holds intermediate-age records.
Characteristics:
- Retention: 7-90 days
- Latency: < 100ms query response
- Technology: SSD-backed database, time-series DB
- Replication: Asynchronous, multi-region
Use cases:
- Trend analysis
- Compliance reporting
- Investigation of recent incidents
Cold Storage¶
Cold storage holds historical records for compliance and forensics.
Characteristics:
- Retention: 1-7+ years (per policy)
- Latency: Minutes to hours (acceptable for archival)
- Technology: Object storage, tape archive
- Replication: Cross-region, immutable
Use cases:
- Legal discovery
- Long-term compliance
- Historical analysis
Retention Policies¶
Each record purpose MUST have an authenticated, versioned policy declaring required evidence, permitted access and recipients, retention trigger, bounded deletion deadline, erasure handling, and responsible authority. Justified holds MUST state scope, authority, end date and review date. Operational, audit, correction and anti-rollback records may have different schedules; none is automatically exempt because it is metadata.
Storage-tier ages above are illustrative service choices, not required retention. The applicable policy MUST govern primary, warm, cold, backup, derivative and federated copies. Restore MUST apply current correction and erasure dispositions before data is made available. Conformance level does not impose a universal period for retaining personal evidence.
Full forensic reconstruction requires retained, decryptable, independently verifiable evidence. After authorized erasure, a verifier MUST distinguish outer-envelope integrity, verified original evidence, and unavailable content or chain segments. A retained disposition can explain a gap, not prove the missing contents. Evidence that is unavailable MUST NOT count as satisfying a current requirement to verify it.
Query Interface¶
Query Language¶
The Flight Recorder MUST provide a query interface supporting:
Temporal Queries¶
Query records by time range:
{
"query": "temporal",
"start": "2025-11-25T00:00:00Z",
"end": "2025-11-25T23:59:59Z",
"record_types": ["authorization_decision", "soul_veto"]
}
Agent Queries¶
Query records for specific agent:
{
"query": "agent",
"agent_id": "agent:7gen:optimized:a1b2c3d4",
"start": "2025-11-01T00:00:00Z",
"include": ["decisions", "tier_transitions", "attestations"]
}
Outcome Queries¶
Query by decision result. The stored fields are supervision and reason; a verb-level query derives from them:
{
"query": "supervision",
"supervision": "silent_veto",
"reason": "TRUST_INSUFFICIENT",
"start": "2025-11-25T00:00:00Z"
}
Environmental Queries¶
Query by environmental conditions:
{
"query": "environment",
"conditions": {
"heat": { "gte": 0.7 },
"r": { "gte": 0.5 }
},
"start": "2025-11-25T00:00:00Z"
}
Counterfactual Queries¶
Query by potential impact:
{
"query": "counterfactual",
"if_allowed": {
"blast_radius.services_affected": { "gte": 10 }
},
"supervision": "silent_veto",
"start": "2025-11-25T00:00:00Z"
}
Common Queries¶
"Show me all prevented incidents today"¶
{
"query": "compound",
"filters": [
{ "record_type": "authorization_decision" },
{ "supervision": "silent_veto" },
{ "counterfactual.if_allowed.blast_radius.services_affected":
{ "gte": 5 } }
],
"start": "2025-11-25T00:00:00Z",
"sort": "counterfactual.if_allowed.blast_radius.services_affected",
"order": "desc"
}
"What was Agent X doing when trust dropped?"¶
{
"query": "correlation",
"anchor": {
"record_type": "trust_score_change",
"agent_id": "agent:7gen:optimized:a1b2c3d4",
"change.delta": { "lte": -10 }
},
"correlate": {
"record_type": "authorization_decision",
"window_before_seconds": 300,
"window_after_seconds": 60
}
}
"Show all Soul vetoes for community X"¶
{
"query": "soul_veto",
"filters": [
{ "soul_constraint.community": "Example Indigenous Community" }
],
"start": "2025-01-01T00:00:00Z"
}
"Agents with highest veto rate this week"¶
{
"query": "aggregate",
"record_type": "authorization_decision",
"group_by": "agent_id",
"metrics": [
{ "name": "total_decisions", "function": "count" },
{ "name": "vetoes", "function": "count",
"filter": { "supervision": "silent_veto" } },
{ "name": "veto_rate", "function": "ratio",
"numerator": "vetoes", "denominator": "total_decisions" }
],
"start": "2025-11-18T00:00:00Z",
"sort": "veto_rate",
"order": "desc",
"limit": 10
}
Forensic Reconstruction¶
The Flight Recorder MUST support forensic reconstruction for the declared period during which the required evidence is retained and available. It MUST report the verification limits of corrected or erased evidence under specifications/privacy-evidence.md and MUST NOT imply full reconstruction after required content or keys are unavailable.
Reconstruction query:
{
"query": "reconstruct",
"record_id": "dr-uuid-12345",
"include": [
"full_risk_factors",
"sensor_values",
"agent_trajectory",
"oracle_state",
"pep_configuration"
]
}
Reconstruction output:
{
"reconstruction": {
"record_id": "dr-uuid-12345",
"timestamp": "2025-11-25T14:32:07.123Z",
"complete": true,
"risk_factors": {
"evidence_density": { "value": 0.45, "feeds": [...] },
"trust_trend": { "value": 0.78, "feeds": [...] },
...
},
"agent_trajectory": {
"last_100_actions": [...],
"trust_history_1h": [...]
},
"decision_replay": {
"step_1_soul_check": "pass",
"step_2_tier_check": "pass",
"step_3_zeroth_law": "fail",
"deterministic": true,
"same_outcome_on_replay": true
}
}
}
Accountability Analysis¶
Human Negligence vs. Environmental Force¶
A key use of the Flight Recorder is distinguishing between:
-
Human negligence: A human made a decision that violated policy or caused harm through carelessness.
-
Environmental force majeure: The system correctly responded to environmental conditions beyond anyone's control.
The Decision Geometry provides the evidence:
Negligence indicators:
- Action was allowed despite high risk
- Trust Score was artificially elevated
- Sensor data was ignored or overridden
- Policy was modified without authorization
Force majeure indicators:
- Action was correctly vetoed by the constraints
- Environmental conditions changed rapidly
- All sensors functioning correctly
- System behaved according to specification
Attribution Framework¶
The Flight Recorder enables precise attribution:
+------------------+--------------------------------------------+
| Question | Flight Recorder Evidence |
+------------------+--------------------------------------------+
| Who requested? | agent_id, session, source_ip |
| What was asked? | action.method, action.resource |
| When? | timestamp |
| What was state? | environment.risk_factors, e_trust |
| What decided? | decision.outcome, decision.reason |
| Why? | decision.evaluation, counterfactual |
| What was impact? | counterfactual.if_allowed.blast_radius |
+------------------+--------------------------------------------+
Liability Boundaries¶
The Flight Recorder creates clear liability boundaries:
If action was vetoed:
- System functioned correctly
- Damage was prevented
- Liability lies with environmental conditions
- No human negligence (unless sensors were manipulated)
If action was allowed and caused harm:
- Was A correctly classified? (If not: policy author liable)
- Was E_trust correctly calculated? (If not: Oracle operator liable)
- Were sensors functioning? (If not: operations liable)
- Was PEP functioning? (If not: infrastructure liable)
- Were all systems correct? (If yes: environmental conditions changed faster than system could respond - force majeure)
External Integration¶
SIEM Integration¶
Flight Recorder records SHOULD support minimized, purpose-authorized SIEM exports. Every export is a separately inventoried copy with declared recipient access, retention, correction, and erasure obligations. The examples below describe software-agent fields and MUST NOT be filled with invented human scores:
Export format (CEF):
CEF:0|NMCITRA|KTP|1.0|DENY|Trust Insufficient|7|
src=10.0.1.45 suser=agent:7gen:optimized:a1b2c3d4
act=DELETE request=/api/users/12345 reason=TRUST_INSUFFICIENT
cs1=85 cs1Label=ActionRisk cs2=42 cs2Label=ETrust
cs3=0.52 cs3Label=RiskFactor
Export format (JSON):
{
"event_type": "ktp_authorization",
"timestamp": "2025-11-25T14:32:07.123Z",
"agent": "agent:7gen:optimized:a1b2c3d4",
"action": "DELETE /api/users/12345",
"supervision": "silent_veto",
"reason": "TRUST_INSUFFICIENT",
"action_risk": 85,
"e_trust": 42,
"r": 0.52
}
Compliance Export¶
Flight Recorder MUST support compliance-ready exports:
SOC 2 format:
- Control evidence mapping
- Exception reports
- Access logs
GDPR format:
- Data subject access requests
- Processing activity records
- Consent verification
HIPAA format:
- Access audit trails
- Disclosure tracking
- Security incident documentation
Machine Learning Pipeline¶
The following software-agent calibration examples require the approved data policy to authorize each source, purpose, recipient and retention schedule. Human eligibility evidence MUST NOT feed generalized behavior, performance, personality, emotion or loyalty scoring. Merely labeling an export anonymized is insufficient. Subject to those limits, permitted data may support:
-
Anomaly detection: Learn normal patterns, alert on deviation
-
Trust prediction: Predict E_trust trajectory from current conditions
-
Risk calibration: Learn optimal A values from historical outcomes
-
Sensor validation: Detect sensor drift or manipulation
ML export format:
{
"features": {
"agent_generation": 7,
"e_base": 87,
"r": 0.52,
"evidence_density": 0.45,
"trust_trend": 0.78,
"adversarial_pressure": 0.82,
"moment_criticality": 0.30,
"update_resistance": 0.25,
"attestation_coverage": 0.15,
"action_risk": 85,
"hour_of_day": 14,
"day_of_week": 1
},
"label": {
"supervision": "silent_veto",
"correct": true
}
}
Security Considerations¶
Record Confidentiality¶
Flight Recorder records contain sensitive information.
Mitigations:
- Encrypt records at rest
- Encrypt records in transit
- Implement role-based access to queries
- Audit all query access
- Generate purpose-authorized redacted views for lower-privilege queries; never alter the original signed bytes or imply that the original signature covers the view
Record Integrity¶
Attackers may attempt to modify records to hide activity.
Mitigations:
- Cryptographic chaining (Section 5.2)
- External chain anchors
- Multi-party signing of records
- Tamper detection alerts (Section 5.3)
Availability¶
The Flight Recorder is critical infrastructure.
Mitigations:
- Multi-region replication
- Asynchronous replication only where permitted by the operation's audit requirements; required durable audit evidence MUST be established before an action depends on it
- Queue-based architecture for resilience
- Regular backup and recovery testing