Interoperable Digital Sky Service Provider Specification

Version 1.0 provides an initial IDSP architecture from a deterministic arbitration framework into a complete national interoperability and safety infrastructure specification.

Enhancements include:

Identity lifecycle and role governance
Tactical real-time coordination standardization
Swarm operations governance
Infrastructure object modeling (corridors, ports, reserved volumes)
Risk classification integration (ARC, SAIL, OSO)
Emergency override and ATC interface standardization
Performance and scalability norms
Operational hardening under extreme conditions
Surge and partition safeguards

1 Scope

1.1 Purpose

This specification defines the complete interoperability, governance, safety, performance, and resilience architecture governing multi-UTMSP coordination within the national UTM ecosystem.

NIDSP 1.1 establishes a deterministic, auditable, sovereign-grade framework that enables:

Structured flight planning and arbitration
Real-time tactical coordination
Swarm and grouped operations
Persistent infrastructure modeling
Risk-aware operational governance
Emergency airspace override
Scalable national deployment

This specification SHALL serve as the authoritative technical standard for interoperable Digital Sky operations.

1.2 System Objectives

NIDSP 1.1 SHALL:

Ensure deterministic conflict resolution between UTMSPs.
Preserve separation safety under all operating conditions.
Prevent non-deterministic arbitration outcomes.
Bind operational actions to cryptographically verifiable identity.
Support scalable, high-density airspace environments.
Enable sovereign emergency override without breaking determinism.
Ensure auditability and non-repudiation of all critical actions.
Maintain safety during degraded or partitioned network conditions.

1.3 Applicability

This specification applies to:

All certified UTMSPs
Designated Authorities issuing policy or emergency directives
Infrastructure operators registering airspace objects
Swarm operators participating in grouped operations
Risk dataset authorities

Compliance is mandatory for participation in interoperable operations.

1.4 Non-Replacement Clause

This specification:

SHALL NOT replace aviation law or regulatory authority.
SHALL NOT define proprietary deconfliction algorithms.
SHALL NOT centralize operational optimization.
SHALL operate as a structured interoperability and governance layer above flight permission systems.

2 Normative References

The following modules form integral parts of this specification:

NIDSP-Core v1.1
NIDSP-Policy v1.1
NIDSP-Registry v1.0
NIDSP-Identity v1.0
NIDSP-Planning v1.1
NIDSP-Intelligence v1.1
NIDSP-Tactical v1.0
NIDSP-Swarm v1.0
NIDSP-Infrastructure v1.0
NIDSP-Risk v1.0
NIDSP-Emergency v1.0

All referenced modules SHALL be considered normative.

Conformance

All certified UTMSPs operating within the national airspace interoperability framework SHALL conform to this specification in full.

Partial implementation is not permitted unless explicitly authorized under a controlled migration phase.

3 Definitions and Terms

For the purposes of this specification:

Arbitration — Deterministic resolution of conflict when negotiation does not converge.

ArbitrationPolicy — A signed, versioned rule set defining deterministic ordering and negotiation constraints.

NegotiationEnvelope — Structured message container used in UTMSP–UTMSP negotiation.

OperationalVolume — 3D spatiotemporal airspace claim for a flight operation.

RiskClass — Structured risk abstraction including ARC, SAIL, and safety objectives.

Swarm — Coordinated group of unmanned aircraft operating under shared abstraction.

DroneCorridor — Persistent structured airspace lane registered in Infrastructure module.

EmergencyAirspaceDirective — Time-bounded sovereign override of normal airspace governance.

Safe Holding Mode — Deterministic fallback state during network partition.

4 Architectural Principles

4.1 Layered Modularity

NIDSP SHALL be modular.
Each module SHALL:

Declare responsibilities
Declare non-responsibilities
Expose defined interfaces
Be independently certifiable

Modules SHALL interact only through defined interfaces.

4.2 Separation of Mechanism and Policy

Core SHALL implement negotiation and arbitration mechanics.

Policy SHALL define deterministic priority ordering.

Operational modules SHALL NOT embed arbitration logic.

This separation SHALL prevent hidden priority bias.

4.3 Deterministic Convergence

Identical inputs SHALL produce identical outputs.

Negotiation SHALL terminate only in defined states.

No randomness SHALL influence arbitration.

4.4 Auditability

All state-changing events SHALL:

Be digitally signed
Be timestamped
Be hash-linked
Be immutable

Historical records SHALL NOT be deleted.

4.5 Sovereign Control

Emergency overrides SHALL be possible.

Such overrides SHALL:

Be signed
Be time-bounded
Be auditable
Not corrupt determinism

4.6 Safety First Principle

Under degraded conditions:

Safety SHALL take precedence over availability.

No arbitration SHALL occur with incomplete information.

5 System Architecture Overview

5.1 General Architecture

NIDSP 1.1 defines a layered, deterministic, interoperable architecture governing multi-UTMSP operations.

The architecture SHALL:

Separate operational coordination from arbitration mechanics.
Prevent embedded priority bias.
Maintain cryptographic traceability of all state transitions.
Preserve safety under high-density and degraded conditions.
Support sovereign override without compromising determinism.

The system SHALL operate as a federated interoperability layer across participating UTMSPs.

5.2 Layered Architecture Model

The architecture SHALL consist of the following logical layers:

Layer 1 — Identity Layer

Defines actor identity, role binding, authorization scope, and certificate validation.

Layer 2 — Planning Layer

Defines flight permission abstraction and OperationalVolume submission.

Layer 3 — Intelligence Layer

Provides advisory enrichment including density forecasts and hazard data.

Layer 4 — Tactical Layer

Provides real-time telemetry exchange, conflict advisory, and reroute coordination.

Layer 5 — Core Arbitration Layer

Implements deterministic negotiation state machine and arbitration trigger.

Layer 6 — Policy Layer

Defines deterministic priority ordering and negotiation constraints.

Layer 7 — Risk Layer

Provides structured risk classification input to Planning, Tactical, and Policy.

Layer 8 — Infrastructure Layer

Defines persistent airspace objects including corridors and ports.

Layer 9 — Emergency Layer

Implements sovereign override and ATC coordination.

Layer 10 — Compliance & Certification Layer

Ensures enforcement, audit integrity, and performance validation.

Each layer SHALL expose clearly defined interfaces to adjacent layers.

No layer SHALL bypass Core arbitration authority.

5.3 Logical Interaction Flow

The following high-level interaction flow SHALL govern operations:

Identity validation SHALL occur prior to Planning.
Planning SHALL validate:
AuthorizationScope
Infrastructure constraints
RiskClass assignment
Planning SHALL initiate negotiation via Core when conflict exists.
Tactical SHALL handle real-time coordination.
Tactical SHALL escalate unresolved conflicts to Core.
Core SHALL invoke ArbitrationPolicy deterministically.
Risk SHALL influence Policy but SHALL NOT execute arbitration.
Emergency SHALL inject override directives when required.
All state transitions SHALL be audit-anchored.

5.4 Responsibility Allocation

Core SHALL:

Govern negotiation mechanics.
Detect convergence.
Trigger arbitration.
Enforce deterministic resolution.

Policy SHALL:

Define ordering logic.
Remain immutable during active negotiation.

Identity SHALL:

Validate actor legitimacy.
Enforce authorization scope.
Propagate revocation.

Tactical SHALL:

Exchange telemetry.
Generate ConflictAlerts.
Propose reroutes.
Escalate when required.

Risk SHALL:

Classify operational exposure.
Define separation thresholds.
Provide deterministic Policy inputs.

Infrastructure SHALL:

Register corridors and ports.
Enforce capacity.
Integrate with Tactical and Planning.

Emergency SHALL:

Inject time-bounded override.
Freeze negotiation when required.
Preserve audit integrity.

5.5 Non-Responsibilities

The architecture SHALL NOT:

Centralize airspace optimization.
Define specific trajectory algorithms.
Grant automatic priority to any commercial entity.
Permit arbitration without complete input set.
Allow modules to override deterministic logic outside defined interfaces.

5.6 Data Integrity Model

All modules SHALL adhere to:

Signed message exchange.
Timestamp validation.
Certificate verification.
Replay protection.
Versioned dataset integrity (including Risk datasets).

All cross-module data exchange SHALL be verifiable.

5.7 Audit Anchoring Model

Every state-changing event SHALL generate an AuditRecord.

AuditRecord SHALL include:

event_id
module_origin
timestamp
identity_id
object_reference
hash_of_previous_record
digital_signature

Audit records SHALL form a hash-linked chain.

Tampering SHALL be detectable.

5.8 Deterministic Boundary Conditions

Under extreme conditions:

Storm compression SHALL apply.
Surge prioritization SHALL apply.
Safe Holding Mode SHALL apply during partition.
Emergency precedence SHALL be deterministic.

These safeguards SHALL preserve systemic integrity.

5.9 Scalability Model

The architecture SHALL:

Support high-density urban airspace.
Support large swarm formations.
Support emergency injection at national scale.
Maintain bounded latency under certified peak load.

Scalability SHALL NOT compromise determinism.

5.10 Governance Boundary

NIDSP SHALL operate as:

Interoperability mechanism
Governance enforcement layer
Safety preservation protocol

It SHALL NOT function as centralized traffic optimizer.

6 NIDSP-Core v1.1

Deterministic Negotiation and Arbitration Engine

6.1 Scope

The Core module SHALL define the deterministic interoperability mechanism governing negotiation and arbitration between certified UTMSPs.

The Core module SHALL:

Implement the negotiation state machine.
Enforce round discipline and timeout control.
Detect convergence or deadlock.
Trigger arbitration when required.
Bind to ArbitrationPolicy deterministically.
Anchor all state transitions in the audit chain.
Enforce replay protection and message integrity.

The Core module SHALL NOT:

Compute trajectory optimization.
Evaluate mission commercial value.
Modify RiskClass.
Override Policy logic.
Issue flight permissions.
Bypass Identity validation.

6.2 Core Responsibilities

Core SHALL act as the sole authority for:

Managing negotiation sessions.
Validating negotiation inputs.
Enforcing deterministic convergence.
Triggering arbitration.
Producing final resolution state.

No other module SHALL independently resolve multi-UTMSP conflicts.

6.3 Negotiation Session

6.3.1 Session Creation

A negotiation session SHALL be created when:

Two or more OperationalVolumes intersect.
Tactical escalation is triggered.
Infrastructure conflict arises.
Emergency re-evaluation is required.

Each session SHALL be assigned:

negotiation_id (UUID)
participating_utms_ids
affected_flight_ids
session_start_timestamp
policy_version_reference
initial_snapshot_hash

6.3.2 Deterministic Snapshot

Upon session creation, Core SHALL:

Capture immutable snapshot of all inputs.
Include RiskClass references.
Include infrastructure constraints.
Include swarm identifiers.
Include emergency flags.

This snapshot SHALL serve as deterministic baseline.

6.4 NegotiationEnvelope Structure

Each negotiation message SHALL contain:

envelope_id (UUID)
negotiation_id
originating_utms_id
target_utms_id
flight_id(s)
operational_volume_hash
proposal_payload_hash
round_number
timestamp (UTC)
nonce
digital_signature

Duplicate envelope_id SHALL be rejected.

Invalid signature SHALL invalidate envelope.

6.5 State Machine

Core SHALL enforce the following states:

INITIATED
NEGOTIATING
CONVERGED
ESCALATED
ARBITRATION_PENDING
RESOLUTION_FINALIZED
DEADLOCK

Transitions SHALL be deterministic.

Undefined states SHALL NOT exist.

6.6 Round Discipline

6.6.1 Maximum Rounds

Maximum negotiation rounds SHALL be defined in ArbitrationPolicy.

6.6.2 Round Ordering

Messages SHALL be processed in deterministic order:

Sorted by timestamp.
Tie-broken by UTMSP identifier.
Verified against nonce sequence.

6.6.3 Round Timeout

If no valid response is received within configured timeout:

Escalation SHALL occur.

6.7 Convergence Detection

Negotiation SHALL be considered CONVERGED when:

All participating UTMSPs submit identical compatible proposal state.
OperationalVolume constraints are satisfied.
Risk and Infrastructure validation passes.

Convergence SHALL generate AuditRecord.

6.8 Escalation

Escalation SHALL occur when:

Maximum rounds exceeded.
Timeout exceeded.
Tactical escalation triggered.
Emergency injection occurs.
Deadlock detected.

Upon escalation:

State SHALL transition to ARBITRATION_PENDING.

6.9 Arbitration

6.9.1 Arbitration Trigger

Core SHALL invoke ArbitrationPolicy using deterministic input snapshot.

6.9.2 Deterministic Ordering

Identical input snapshot SHALL produce identical arbitration outcome.

No randomness SHALL be used.

6.9.3 Tie-Break

Tie-break SHALL follow ordering defined in Policy.

6.10 Storm Compression Mode

If N-way conflict cluster detected:

Core SHALL:

Aggregate affected sessions.
Create arbitration cluster.
Produce single deterministic resolution.

Storm Compression SHALL NOT alter Policy rules.

6.11 Swarm Handling

If swarm_flag \= true:

Core SHALL treat swarm as grouped negotiation entity.
Partial arbitration SHALL be prohibited unless explicitly enabled.

Swarm resolution SHALL apply to all swarm members.

6.12 Emergency Freeze Window

Upon EmergencyAirspaceDirective with priority_override_flag:

Core SHALL:

Freeze active negotiation sessions within affected_geometry.
Capture snapshot.
Re-evaluate deterministically.

Freeze SHALL be time-bounded.

6.13 Network Partition Handling

If communication partition detected:

Core SHALL:

Enter Safe Holding Mode.
Suspend arbitration.
Preserve last valid snapshot.
Prevent divergent outcomes.

Upon reconnection:

State reconciliation SHALL occur using last audit-anchored state.

6.14 Safety Deadlock

If arbitration cannot produce safe resolution:

State SHALL transition to DEADLOCK.

Deadlock SHALL:

Trigger Compliance event.
Prevent flight execution in affected region.
Preserve separation safety.

6.15 Replay Protection

Core SHALL reject:

Duplicate envelope_id.
Expired timestamps.
Invalid nonce sequence.
Invalid signature.
Revoked certificate origin.

Replay attempts SHALL generate AuditRecord.

6.16 Audit Requirements

The following SHALL generate AuditRecord:

Session creation.
State transition.
Escalation.
Arbitration outcome.
Deadlock.
Freeze window activation.
Partition entry and exit.

Audit records SHALL be hash-linked.

6.17 Performance Guarantees

Core SHALL:

Complete arbitration within configured maximum bound.
Maintain deterministic message ordering under load.
Preserve state integrity during failover.

Core SHALL maintain minimum 99.95% uptime.

6.18 Non-Responsibilities

Core SHALL NOT:

Compute flight path optimization.
Override Risk thresholds.
Modify Identity records.
Grant automatic priority outside Policy.
Delete historical audit entries.

6.19 Certification Requirements

Certification SHALL validate:

Deterministic repeatability under identical inputs.
Storm compression correctness.
Swarm cluster arbitration stability.
Emergency freeze correctness.
Partition recovery integrity.
Deadlock safety preservation.
Replay protection enforcement.

7 NIDSP-Policy v1.1

Deterministic Arbitration Policy Framework

7.1 Scope

The Policy module SHALL define the deterministic rule set governing negotiation constraints and arbitration ordering within NIDSP.

The Policy module SHALL:

Define arbitration priority ordering.
Define negotiation limits.
Define tie-break logic.
Accept structured inputs from Risk, Swarm, Infrastructure, and Emergency modules.
Be versioned and cryptographically signed.
Remain immutable during active negotiation.

The Policy module SHALL NOT:

Execute negotiation mechanics.
Compute trajectory optimization.
Modify Identity records.
Override regulatory separation minima.
Embed non-deterministic logic.

7.2 ArbitrationPolicy Object

Each ArbitrationPolicy SHALL contain:

policy_id (UUID)
version
effective_from_timestamp
effective_until_timestamp (optional)
max_negotiation_rounds
negotiation_timeout_seconds
ordering_rule_set
tie_break_rule
storm_compression_threshold
swarm_priority_rule (optional)
infrastructure_priority_rule (optional)
risk_weighting_rule (optional)
emergency_override_rule
digital_signature (Designated Authority)

7.3 Deterministic Ordering Rule Set

7.3.1 Ordering Inputs

Policy MAY consider the following deterministic inputs:

mission_classification
RiskClass (ARC, SAIL, GroundRiskClass)
swarm_flag
swarm_size
infrastructure_class
priority_class
emergency_override_flag
timestamp_of_submission
UTMSP_identifier

All inputs SHALL be captured in immutable snapshot prior to evaluation.

7.3.2 Ordering Requirements

Ordering SHALL:

Be strictly deterministic.
Produce total ordering (no ambiguity).
Produce identical results for identical inputs.
Avoid random selection.

7.3.3 Prohibited Ordering Logic

Policy SHALL NOT:

Use probabilistic functions.
Use runtime load metrics.
Use unverified external inputs.
Allow UTMSP self-declared priority without authority validation.

7.4 Tie-Break Rule

If ordering inputs result in equal priority score:

Tie-break SHALL occur using:

Deterministic lexicographic ordering of UTMSP_identifier.
If still equal, deterministic ordering of flight_id.
If still equal, earliest submission timestamp.

No undefined tie state SHALL exist.

7.5 Risk Weighting Rule

If risk_weighting_rule is enabled:

ARC_class MAY influence ordering.
Higher safety-critical classification MAY increase priority weight.
GroundRiskClass MAY influence emergency escalation priority.

Risk weighting SHALL NOT reduce regulatory separation threshold.

Risk weighting SHALL remain deterministic.

7.6 Swarm Priority Rule

If swarm_priority_rule is enabled:

Swarm size MAY influence priority.
Swarm mission classification MAY influence priority.
Swarm SHALL be treated as single arbitration entity.

Swarm priority SHALL NOT bypass emergency precedence.

7.7 Infrastructure Priority Rule

If infrastructure_priority_rule is enabled:

DroneCorridor priority_class MAY influence ordering.
ReservedVolume critical designation MAY influence ordering.

Infrastructure priority SHALL NOT override Emergency override rule.

7.8 Emergency Override Rule

If emergency_override_flag \= true:

Policy SHALL:

Elevate emergency-classified flights to highest ordering tier.
Preserve deterministic ordering among emergency flights using tie-break rule.

Emergency override SHALL be time-bounded.

7.9 Negotiation Constraints

Policy SHALL define:

Maximum rounds allowed.
Maximum negotiation duration.
Conditions triggering escalation.
Storm compression threshold.
Swarm arbitration compression condition.

Constraints SHALL be strictly enforced by Core.

7.10 Policy Immutability

During active negotiation:

Policy version SHALL remain fixed.
Policy SHALL NOT change mid-session.
New policy versions SHALL apply only to new negotiation sessions.

7.11 Policy Versioning

Each policy version SHALL:

Be uniquely versioned.
Be signed by Designated Authority.
Be audit-anchored.
Include effective validity period.

Expired policies SHALL NOT be used in new sessions.

7.12 Policy Integrity

Policy SHALL be:

Cryptographically signed.
Hash-anchored in audit chain.
Publicly verifiable.

Tampered policy SHALL invalidate negotiation.

7.13 Policy Activation & Deactivation

Activation SHALL:

Generate AuditRecord.
Be propagated to all UTMSPs.

Deactivation SHALL:

Generate AuditRecord.
Preserve historical record.

7.14 Surge Prioritization Integration

If Surge Prioritization Mode is activated:

Policy SHALL temporarily enforce:

Emergency flights
High RiskClass flights
Swarm operations
Standard operations

Surge prioritization SHALL be deterministic and auditable.

7.15 Certification Requirements

Certification SHALL verify:

Deterministic repeatability.
Tie-break stability.
Risk weighting consistency.
Swarm weighting stability.
Infrastructure priority correctness.
Emergency override correctness.
Storm compression behavior.

Certification SHALL include identical-input replay testing.

7.16 Non-Responsibilities

Policy SHALL NOT:

Compute reroutes.
Perform conflict detection.
Modify Infrastructure objects.
Modify RiskClass.
Delete historical records.
Override Emergency precedence rules.

8 NIDSP-Registry v1.0

National UIN and Asset Registry Governance

8.1 Scope

The Registry module SHALL define the governance, lifecycle, and interoperability rules for unmanned aircraft identifiers (UIN), asset binding, and custodial continuity across UTMSPs.

The Registry module SHALL:

Define UIN namespace structure.
Ensure global uniqueness of identifiers.
Bind UIN to certified Identity.
Support portability between UTMSPs.
Anchor registry events in audit chain.
Prevent identifier duplication or reassignment ambiguity.

The Registry module SHALL NOT:

Issue flight permissions.
Execute arbitration.
Override Identity module.
Modify RiskClass.
Permit deletion of historical records.

8.2 UIN Namespace

8.2.1 UIN Structure

Each unmanned aircraft SHALL be assigned a globally unique UIN.

UIN SHALL:

Be immutable for lifetime of aircraft.
Be unique across national namespace.
Be verifiable through Registry lookup.

UIN format SHALL be:

Structured
Versioned
Machine-parseable

8.2.2 UIN Integrity

Duplicate UIN issuance SHALL be prohibited.

Registry SHALL validate uniqueness prior to issuance.

Tampering or reuse SHALL trigger Compliance event.

8.3 Asset Binding

Each UIN SHALL be bound to:

Manufacturer identity_id
Operator identity_id
Device certificate fingerprint
Model classification
Airworthiness status (if applicable)

Binding SHALL be cryptographically verifiable.

8.4 Custodial Continuity

8.4.1 Operator Transfer

When aircraft changes operator:

UIN SHALL remain unchanged.
Operator binding SHALL update.
Transfer SHALL be signed by both parties.
AuditRecord SHALL be generated.

8.4.2 UTMSP Portability

Aircraft SHALL be portable between UTMSPs without requiring new UIN issuance.

Portability SHALL:

Preserve audit continuity.
Preserve Risk history (where applicable).
Not alter identity binding.

8.5 Device Certificate Binding

Each UIN SHALL be associated with:

X.509 device certificate
Public key fingerprint
Certificate validity period

Certificate SHALL:

Be verifiable under sovereign Root CA.
Be revocable.
Be checked prior to Tactical participation.

8.6 Registry Lookup Requirements

Registry SHALL support:

Deterministic lookup by UIN.
Lookup by identity_id.
Verification of certificate binding.
Verification of current operator.

Lookup latency SHALL comply with performance section.

8.7 Registry Update Lifecycle

8.7.1 Creation

UIN issuance SHALL:

Be performed by authorized issuing authority.
Be signed.
Be audit-anchored.

8.7.2 Update

Registry update SHALL:

Preserve UIN.
Increment version.
Generate AuditRecord.

8.7.3 Suspension

Suspension SHALL:

Temporarily prohibit operation.
Propagate to Tactical and Core.
Be auditable.

8.7.4 Revocation

Revocation SHALL:

Permanently disable operation.
Prevent negotiation participation.
Be audit-anchored.

Historical records SHALL remain preserved.

8.8 Registry and Identity Integration

Registry SHALL validate:

IdentityRecord exists and is active.
AuthorizationScope permits binding.
Certificate fingerprint matches Identity record.

Registry SHALL reject binding attempts from revoked identities.

8.9 Registry and Tactical Integration

Prior to accepting TelemetryObject:

Tactical SHALL verify:

UIN exists.
Certificate fingerprint matches registry.
UIN not suspended or revoked.

Invalid UIN SHALL be rejected.

8.10 Registry and Risk Integration

RiskClass MAY reference UIN.

Registry SHALL preserve aircraft model and configuration metadata necessary for Risk evaluation.

Registry SHALL NOT compute RiskClass.

8.11 Audit Requirements

The following SHALL generate AuditRecord:

UIN issuance
Operator transfer
Certificate binding
Suspension
Revocation
Metadata update

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

8.12 Data Integrity Requirements

Registry SHALL:

Store versioned records.
Protect against unauthorized modification.
Enforce strong authentication for updates.
Validate digital signatures.

Corrupted registry entry SHALL trigger degraded mode for affected aircraft.

8.13 Performance Requirements

Registry lookup SHALL complete within:

1000 milliseconds under nominal load.

Registry SHALL support:

National-scale asset count.
Concurrent lookups under peak telemetry load.

8.14 Certification Requirements

Certification SHALL verify:

UIN uniqueness enforcement.
Transfer continuity correctness.
Certificate binding validation.
Revocation propagation.
Replay attempt rejection.
Audit integrity.

Testing SHALL include high-volume lookup simulation.

8.15 Non-Responsibilities

Registry SHALL NOT:

Perform conflict detection.
Execute arbitration.
Assign mission priority.
Modify Infrastructure objects.
Delete historical data.
Override Emergency directive.

9 NIDSP-Identity v1.0

Actor Identity, Role, and Authorization Governance

9.1 Scope

The Identity module SHALL define the lifecycle, structure, validation, authorization, and revocation governance of all actors participating in the NIDSP ecosystem.

The Identity module SHALL:

Define actor categories.
Define IdentityRecord schema.
Define role classification and authorization scope.
Bind identities to cryptographic credentials.
Enforce revocation propagation.
Anchor all identity state transitions in the audit chain.
Integrate with Registry, Planning, Tactical, Risk, Infrastructure, and Core modules.

The Identity module SHALL NOT:

Execute negotiation.
Perform arbitration.
Compute deconfliction.
Override ArbitrationPolicy.
Modify Infrastructure objects.

9.2 Actor Categories

The following actor categories SHALL be recognized:

UTMSP
Unmanned Aircraft Operator (UAO)
Remote Pilot
Manufacturer
Infrastructure Operator
Designated Authority
Compliance Authority

Each actor SHALL possess exactly one primary IdentityRecord.

An actor MAY hold multiple roles, but each role SHALL be explicitly declared and authorized.

9.3 IdentityRecord Structure

Each IdentityRecord SHALL include:

identity_id (UUID, globally unique and immutable)
actor_category
legal_name
jurisdiction_identifier
registration_identifier (if applicable)
contact_endpoint
role_assignments
authorization_scope
certificate_fingerprint
status (Active, Suspended, Revoked)
effective_from
effective_until (optional)
version
digital_signature (issuing authority)

IdentityRecord SHALL be versioned.

identity_id SHALL remain immutable throughout lifecycle.

9.4 Role Classification

Each role SHALL define:

Operational privileges
Data access permissions
Negotiation participation eligibility
Swarm participation eligibility
Infrastructure creation rights
Emergency issuance rights (if applicable)

Role escalation SHALL require authorization from Designated Authority.

Unauthorized role change SHALL be rejected.

Role definitions SHALL be versioned and signed.

9.5 Authorization Scope

AuthorizationScope SHALL define operational boundaries applicable to identity.

AuthorizationScope MAY include:

Geographic limits
Altitude limits
Maximum RiskClass permitted
Maximum swarm size
Infrastructure interaction permissions
Mission classification limits

Planning and Tactical modules SHALL validate AuthorizationScope prior to operational acceptance.

Violation SHALL trigger Compliance event.

9.6 Credential Binding

Each IdentityRecord SHALL be bound to:

X.509 certificate
Public key fingerprint
Certificate validity period

Certificate SHALL:

Be issued under sovereign Root CA
Be verifiable via revocation check
Be required for message signing

All signed messages SHALL be validated against stored certificate fingerprint.

Expired or revoked certificates SHALL invalidate operational participation.

9.7 Identity Lifecycle

9.7.1 Creation

IdentityRecord SHALL be created by authorized issuing authority.

Creation SHALL:

Generate identity_id
Assign roles
Bind certificate
Generate AuditRecord

9.7.2 Update

Identity update SHALL:

Preserve identity_id
Increment version
Require digital signature
Generate AuditRecord

9.7.3 Suspension

Suspension SHALL:

Immediately prohibit new negotiation participation
Prohibit Tactical message acceptance
Propagate to Core and Registry
Generate AuditRecord

9.7.4 Revocation

Revocation SHALL:

Permanently disable participation
Prevent Planning acceptance
Prevent Tactical message processing
Generate Compliance notification
Generate AuditRecord

Historical records SHALL remain immutable.

9.8 Mid-Flight Revocation Handling

If identity is revoked during active flight:

Tactical SHALL issue DIRECTIVE advisory.
Core SHALL block new negotiation involving revoked identity.
Compliance SHALL be notified.
Emergency escalation MAY occur if safety risk is detected.

Completed arbitration outcomes SHALL remain immutable.

9.9 Swarm Identity Binding

Swarm SHALL reference:

lead_operator_identity_id
participating_identity_ids

All identities SHALL be active and authorized.

Swarm participation SHALL NOT expand AuthorizationScope.

9.10 Infrastructure Identity Binding

Infrastructure objects SHALL reference:

infrastructure_operator_identity_id

Unauthorized identities SHALL NOT create or modify infrastructure.

Ownership transfer SHALL require signed update and AuditRecord.

9.11 Identity Integration with Other Modules

Registry Integration

Registry SHALL validate active Identity prior to UIN binding.

Planning Integration

Planning SHALL validate AuthorizationScope.

Tactical Integration

Tactical SHALL validate certificate and identity status for each TelemetryObject.

Core Integration

Core SHALL reject NegotiationEnvelope from revoked identity.

Emergency Integration

Only authorized identities SHALL issue EmergencyAirspaceDirective.

9.12 Revocation Propagation Requirements

Revocation SHALL propagate to:

Core
Registry
Tactical
Planning
Compliance

Propagation delay SHALL comply with performance norms.

Messages from revoked identity SHALL be rejected.

9.13 Audit Requirements

The following SHALL generate AuditRecord:

Identity creation
Role assignment
Authorization change
Certificate binding
Suspension
Revocation
Mid-flight revocation event

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

9.14 Data Integrity & Security

Identity data SHALL:

Be protected against unauthorized modification
Require strong authentication for update
Be stored in versioned format
Be cryptographically verifiable

Compromised identity SHALL trigger Compliance escalation.

9.15 Performance Requirements

Identity validation SHALL complete within:

500 milliseconds per validation

Revocation check SHALL complete within:

1000 milliseconds

9.16 Certification Requirements

Certification SHALL verify:

Certificate validation correctness
Revocation propagation speed
AuthorizationScope enforcement
Role assignment stability
Mid-flight revocation handling
Deterministic validation behavior under load

9.17 Non-Responsibilities

Identity SHALL NOT:

Perform arbitration
Compute reroutes
Assign mission priority
Modify Infrastructure geometry
Delete historical audit records

10 NIDSP-Planning v1.1

Flight Planning and Permission Abstraction Governance

10.1 Scope

The Planning module SHALL define the structured submission, validation, and negotiation initiation process for flight operations within the NIDSP ecosystem.

The Planning module SHALL:

Define OperationalVolume structure.
Validate AuthorizationScope.
Inject RiskClass.
Validate Infrastructure constraints.
Integrate advisory input from Intelligence.
Initiate negotiation through Core when required.
Anchor planning decisions in audit chain.

The Planning module SHALL NOT:

Perform arbitration.
Override ArbitrationPolicy.
Execute real-time deconfliction.
Modify Risk thresholds.
Bypass Identity validation.

10.2 Flight Intent Submission

Each flight operation SHALL begin with submission of FlightIntent.

FlightIntent SHALL include:

flight_id (UUID)
operator_identity_id
UIN
mission_classification
OperationalVolume
requested_time_window
swarm_flag (if applicable)
infrastructure_reference (if applicable)
declared Risk parameters (if applicable)
digital_signature

FlightIntent SHALL be validated against Identity and Registry prior to acceptance.

10.3 OperationalVolume Structure

OperationalVolume SHALL define:

3D geographic boundary (latitude, longitude, altitude)
time_window
contingency_buffer
maximum_velocity
optional corridor alignment

OperationalVolume SHALL:

Be deterministic.
Be machine-parseable.
Be immutable once negotiation begins.

Modifications SHALL generate new version and AuditRecord.

10.4 Authorization Validation

Planning SHALL validate:

Operator Identity active status.
AuthorizationScope compatibility.
Swarm eligibility (if applicable).
Infrastructure interaction rights.

Violation SHALL result in rejection and AuditRecord.

10.5 Risk Injection

Planning SHALL assign RiskClass during submission.

RiskClass SHALL include:

ARC classification
SAIL level
GroundRiskClass
Operational Safety Objectives

RiskClass SHALL be audit-anchored.

RiskClass SHALL remain immutable during negotiation session.

10.6 Infrastructure Validation

Planning SHALL validate:

DroneCorridor geometry compliance.
DronePort availability.
ReservedVolume restrictions.
TemporaryInfrastructureZone restrictions.

Conflict SHALL:

Trigger negotiation through Core.
Generate AuditRecord.

Infrastructure SHALL NOT automatically grant permission.

10.7 Swarm Planning Extension

If swarm_flag \= true:

Planning SHALL:

Assign swarm_id.
Validate participating_identity_ids.
Define shared_operational_volume.
Validate swarm_size limit.
Inject swarm_risk_id.

Swarm planning SHALL NOT expand AuthorizationScope.

10.8 Advisory Integration

Planning MAY request advisory input from Intelligence module.

Advisory SHALL:

Be non-binding.
Provide density forecast.
Provide hazard notification.
Provide confidence indicator.

Planning SHALL record advisory reference in AuditRecord.

Advisory SHALL NOT override regulatory constraints.

10.9 Conflict Detection and Escalation

Planning SHALL detect:

Overlapping OperationalVolume.
Infrastructure capacity exceedance.
Risk incompatibility.

Upon detection:

Planning SHALL initiate negotiation session in Core.

Planning SHALL NOT independently resolve multi-UTMSP conflicts.

10.10 Negotiation Initiation

When conflict exists:

Planning SHALL:

Generate NegotiationEnvelope.
Submit immutable snapshot to Core.
Include Policy version reference.
Include RiskClass reference.
Include Infrastructure reference.

Core SHALL assume authority after submission.

10.11 Approval State

Planning SHALL support the following states:

SUBMITTED
VALIDATED
NEGOTIATION_PENDING
APPROVED
DENIED
SUSPENDED

State transitions SHALL generate AuditRecord.

Approval SHALL require:

Identity validation
RiskClass assignment
Infrastructure validation
Core convergence or arbitration resolution

10.12 Modification Handling

FlightIntent modification SHALL:

Generate new version.
Trigger revalidation.
Trigger new negotiation if necessary.
Preserve previous version in audit chain.

Modification SHALL NOT alter existing arbitration result retroactively.

10.13 Emergency Interaction

If EmergencyAirspaceDirective affects submitted or approved flight:

Planning SHALL:

Revalidate against directive.
Initiate negotiation if required.
Suspend approval if mandated.

Emergency revalidation SHALL be audit-anchored.

10.14 Performance Requirements

Planning validation SHALL complete within:

2000 milliseconds under nominal load.

Conflict detection SHALL not exceed:

1000 milliseconds.

Planning SHALL scale to national flight density levels.

10.15 Audit Requirements

The following SHALL generate AuditRecord:

FlightIntent submission
Validation success or rejection
RiskClass assignment
Infrastructure validation
Negotiation initiation
Approval
Denial
Modification
Emergency revalidation

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

10.16 Degraded Mode Handling

If system enters degraded mode:

New non-critical flight submissions MAY be restricted.
Emergency flights SHALL remain permitted.
Approved flights SHALL maintain safety guarantees.
Arbitration SHALL not occur with incomplete input.

Degraded mode activation SHALL generate AuditRecord.

10.17 Certification Requirements

Certification SHALL validate:

Deterministic OperationalVolume handling.
AuthorizationScope enforcement.
Infrastructure validation correctness.
Risk injection stability.
Swarm planning integrity.
Emergency revalidation correctness.
Performance bounds compliance.

10.18 Non-Responsibilities

Planning SHALL NOT:

Execute arbitration.
Compute dynamic reroutes.
Modify RiskClass post-negotiation.
Override Emergency directives.
Delete historical planning records.

11 NIDSP-Intelligence v1.1

Advisory, Forecasting, and Hazard Information Layer

11.1 Scope

The Intelligence module SHALL define the structured advisory and predictive data services available to Planning and Tactical modules within the NIDSP architecture.

The Intelligence module SHALL:

Define DensityForecast object.
Define HazardObject schema.
Provide advisory enrichment to Planning.
Provide predictive advisory to Tactical.
Include confidence indicators.
Ensure deterministic data structure.
Anchor advisory generation in audit chain.

The Intelligence module SHALL NOT:

Override ArbitrationPolicy.
Execute negotiation.
Modify RiskClass.
Issue flight permissions.
Override Emergency directives.
Perform conflict resolution.

11.2 Purpose

The purpose of the Intelligence module is to enhance situational awareness and proactive safety planning without compromising deterministic arbitration authority.

Intelligence SHALL function as advisory input only.

All binding decisions SHALL remain under Planning, Tactical, Core, and Policy modules.

11.3 Data Sources

Intelligence MAY integrate:

Historical traffic density datasets
Real-time traffic telemetry aggregates
Weather data
Temporary hazard notifications
Infrastructure usage trends
Regulator-issued advisories

All datasets SHALL:

Be versioned.
Be timestamped.
Be cryptographically verifiable where applicable.

11.4 DensityForecast Object

DensityForecast SHALL include:

forecast_id (UUID)
geographic_boundary
altitude_range
time_window
predicted_traffic_density
density_classification (LOW, MEDIUM, HIGH, CRITICAL)
confidence_score (0–1)
dataset_version_reference
generation_timestamp
digital_signature

DensityForecast SHALL:

Be machine-parseable.
Be time-bounded.
Be advisory only.

11.5 HazardObject Schema

HazardObject SHALL include:

hazard_id (UUID)
hazard_type (WEATHER, INFRASTRUCTURE, TEMPORARY_RESTRICTION, OTHER)
geographic_boundary
altitude_range
time_window
severity_level
recommended_action
issuing_authority
digital_signature

HazardObject SHALL:

Be time-bounded.
Be cryptographically verifiable if regulator-issued.
Be advisory unless escalated via Emergency module.

11.6 Advisory Integration with Planning

Planning MAY query Intelligence prior to flight approval.

Planning SHALL:

Record advisory reference.
Not automatically deny flight solely based on advisory.
Consider advisory during OperationalVolume evaluation.

Advisory SHALL NOT replace regulatory constraints.

11.7 Advisory Integration with Tactical

Tactical MAY use Intelligence to:

Predict density escalation.
Issue INFORMATIVE or SUGGESTIVE advisory.
Preemptively suggest reroute.

Intelligence SHALL NOT issue DIRECTIVE advisory.

DIRECTIVE advisory SHALL originate from Tactical logic.

11.8 Confidence Indicators

All predictive data SHALL include confidence_score.

Confidence_score SHALL:

Be deterministic for given dataset.
Be bounded between 0 and 1.
Be auditable.

Low-confidence forecasts SHALL NOT trigger binding restriction.

11.9 Dataset Integrity Requirements

All Intelligence datasets SHALL:

Be versioned.
Be hash-verified.
Be signed by issuing authority if regulator-controlled.
Be audit-anchored upon update.

Corrupted dataset SHALL trigger degraded mode.

11.10 Emergency Interaction

If hazard escalates beyond advisory threshold:

Intelligence SHALL notify Emergency module.
Emergency module SHALL determine binding directive.

Intelligence SHALL NOT independently escalate to binding restriction.

11.11 Audit Requirements

The following SHALL generate AuditRecord:

DensityForecast generation.
HazardObject issuance.
Dataset update.
Advisory referenced during Planning.
Advisory referenced during Tactical escalation.

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

11.12 Performance Requirements

Forecast query SHALL complete within:

1000 milliseconds under nominal load.

Hazard query SHALL complete within:

500 milliseconds.

Bulk forecast generation SHALL NOT block Tactical operations.

11.13 Degraded Mode Handling

If Intelligence becomes unavailable:

Planning SHALL continue using existing regulatory constraints.
Tactical SHALL continue using real-time telemetry only.
Arbitration SHALL remain unaffected.

Intelligence failure SHALL NOT halt Core operation.

Degraded state SHALL generate AuditRecord.

11.14 Certification Requirements

Certification SHALL verify:

Deterministic dataset handling.
Forecast repeatability under identical input.
Advisory integration correctness.
Confidence score stability.
Non-binding enforcement.
Performance bounds compliance.

11.15 Non-Responsibilities

Intelligence SHALL NOT:

Perform arbitration.
Override Policy.
Modify RiskClass.
Enforce flight denial.
Inject Emergency directive.
Modify Infrastructure geometry.

12 NIDSP-Tactical v1.0

Real-Time Coordination and Conflict Advisory Layer

12.1 Scope

The Tactical module SHALL define the real-time operational data exchange, conflict detection, advisory generation, and escalation mechanisms between UTMSPs.

The Tactical module SHALL:

Define TelemetryObject schema.
Define ConflictAlert object.
Define advisory classification levels.
Define DynamicReroute object.
Enforce identity and registry validation.
Enforce rate limiting.
Escalate unresolved conflicts to Core.
Integrate with Risk, Infrastructure, and Swarm modules.
Preserve audit traceability.

The Tactical module SHALL NOT:

Execute arbitration.
Override ArbitrationPolicy.
Modify RiskClass.
Modify Infrastructure objects.
Bypass Emergency directives.
Delete audit records.

12.2 Operational Context

Tactical SHALL operate during:

Active flight operations.
Dynamic reroute events.
Infrastructure occupancy updates.
Swarm maneuver coordination.
Emergency enforcement.
Partition recovery.

Tactical SHALL remain functional independently of Planning once flight is active.

12.3 TelemetryObject

Each active flight SHALL transmit TelemetryObject containing:

flight_id
UIN
identity_id
latitude
longitude
altitude
velocity_vector
heading
timestamp (UTC ISO 8601)
confidence_indicator
nonce
digital_signature

TelemetryObject SHALL:

Be signed.
Be validated against Identity and Registry.
Be rejected if certificate invalid or revoked.
Be rejected if timestamp stale beyond threshold.

12.4 Telemetry Validation

Upon receipt, Tactical SHALL validate:

Identity active status.
UIN existence.
Certificate fingerprint match.
AuthorizationScope compatibility.
Replay protection (nonce uniqueness).
Rate limit compliance.

Invalid telemetry SHALL be rejected and audit-anchored.

12.5 Conflict Detection

Tactical SHALL continuously evaluate:

Separation minima based on RiskClass.
OperationalVolume intersections.
Corridor capacity thresholds.
Swarm topology constraints.
ReservedVolume encroachment.
EmergencyAirspaceDirective compliance.

Conflict detection SHALL be deterministic.

12.6 ConflictAlert Object

Upon predicted or detected violation:

Tactical SHALL generate ConflictAlert containing:

alert_id (UUID)
originating_utms_id
target_utms_id
flight_ids_involved
swarm_id (if applicable)
predicted_intersection_volume
time_window
separation_distance_estimate
risk_level
advisory_level
timestamp
digital_signature

ConflictAlert SHALL NOT contain arbitration decision.

12.7 Advisory Classification

Advisory SHALL be classified as:

INFORMATIVE
SUGGESTIVE
DIRECTIVE

INFORMATIVE

Awareness only.

SUGGESTIVE

Voluntary maneuver proposal.

DIRECTIVE

Mandatory maneuver required to preserve safety.

DIRECTIVE SHALL be based on separation threshold breach.

DIRECTIVE SHALL NOT determine arbitration winner.

12.8 DynamicReroute Object

DynamicReroute SHALL contain:

reroute_id
flight_id
modified_operational_volume
effective_time
justification_code
advisory_level
digital_signature

Reroute SHALL:

Respect AuthorizationScope.
Respect Infrastructure constraints.
Respect Risk thresholds.
Preserve Swarm topology if applicable.

Repeated incompatible reroutes SHALL trigger escalation.

12.9 Escalation to Core

Escalation SHALL occur when:

Negotiation disagreement persists.
Advisory conflict exceeds threshold.
Separation violation remains unresolved.
Emergency revalidation required.
Partition reconciliation required.

Escalation SHALL:

Generate NegotiationEnvelope.
Freeze conflicting Tactical reroutes.
Anchor escalation in audit chain.

12.10 Swarm Integration

If swarm_flag \= true:

ConflictAlert SHALL reference swarm_id.
Reroute SHALL preserve intra-swarm separation.
Swarm split SHALL generate new swarm_id.
Swarm-cluster conflict SHALL escalate as grouped entity.

Partial reroute SHALL NOT occur unless explicitly permitted.

12.11 Infrastructure Enforcement

Tactical SHALL validate:

DroneCorridor boundaries.
DronePort occupancy.
ReservedVolume restrictions.
TemporaryInfrastructureZone restrictions.

Capacity violation SHALL generate advisory within performance bounds.

Emergency override SHALL supersede capacity limit.

12.12 Emergency Enforcement

If EmergencyAirspaceDirective active:

Tactical SHALL:

Validate compliance in real time.
Issue DIRECTIVE advisory for violation.
Escalate persistent violation to Core.
Preserve minimum separation thresholds.

Emergency precedence SHALL follow deterministic rule defined in Policy.

12.13 Rate Limiting

Tactical SHALL enforce:

Telemetry rate limit per identity_id.
Telemetry rate limit per UTMSP.
ConflictAlert emission limit per session.

Excess rate SHALL:

Trigger Compliance event.
Preserve deterministic ordering.

Rate limiting SHALL NOT drop safety-critical messages.

12.14 Network Partition Safe Mode

If connectivity lost between UTMSPs or Core:

Tactical SHALL:

Enter Safe Holding Mode.
Maintain increased separation threshold.
Prevent independent arbitration.
Preserve audit continuity.

Upon reconnection:

State reconciliation SHALL occur using last audit snapshot.

12.15 Replay Protection

Tactical SHALL reject:

Duplicate nonce.
Duplicate message_id.
Expired timestamp.
Invalid signature.
Revoked identity.

Replay attempt SHALL generate AuditRecord.

12.16 Audit Requirements

The following SHALL generate AuditRecord:

Telemetry rejection.
ConflictAlert issuance.
Advisory classification change.
DynamicReroute issuance.
Escalation to Core.
Emergency enforcement.
Rate limit violation.
Partition entry and exit.

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

12.17 Performance Requirements

Tactical SHALL ensure:

Telemetry validation ≤ 500 ms nominal.
ConflictAlert propagation ≤ 1000 ms.
Escalation to Core ≤ 2000 ms.
Occupancy update ≤ 500 ms.

Tactical SHALL maintain minimum 99.9% uptime.

12.18 Certification Requirements

Certification SHALL validate:

Deterministic conflict detection.
Advisory stability.
Swarm reroute integrity.
Infrastructure enforcement correctness.
Emergency enforcement correctness.
Rate limiting behavior.
Partition recovery safety.
Performance bound compliance.

High-density stress simulation SHALL be mandatory.

12.19 Non-Responsibilities

Tactical SHALL NOT:

Determine arbitration winner.
Modify ArbitrationPolicy.
Modify RiskClass.
Issue flight permission.
Override Emergency precedence.
Delete historical audit records.

13 NIDSP-Risk v1.0

Operational Risk Classification and Safety Threshold Governance

13.1 Scope

The Risk module SHALL define the structured classification of operational air and ground risk and the binding of safety thresholds used by Planning, Tactical, and Policy modules.

The Risk module SHALL:

Define RiskClass object.
Define ARC classification.
Define SAIL integrity level.
Define GroundRiskClass.
Define Operational Safety Objectives (OSO).
Bind separation threshold references.
Ensure dataset integrity and version control.
Anchor all risk assignments in audit chain.

The Risk module SHALL NOT:

Execute arbitration.
Compute reroute trajectories.
Override ArbitrationPolicy.
Modify Identity or Registry records.
Reduce regulatory separation minima.

13.2 RiskClass Object

Each planned flight SHALL reference a RiskClass.

RiskClass SHALL include:

risk_id (UUID)
flight_id
ARC_class
SAIL_level
GroundRiskClass
OperationalSafetyObjectives (OSO list)
separation_threshold_reference
swarm_risk_flag (if applicable)
effective_time_window
dataset_version_reference
issuing_authority
digital_signature

RiskClass SHALL be immutable once negotiation session begins.

Modification SHALL require new version and AuditRecord.

13.3 ARC Classification

ARC_class SHALL represent air risk exposure classification.

ARC_class SHALL:

Be derived deterministically from approved dataset.
Consider airspace complexity and traffic density.
Be version-controlled.
Be cryptographically verifiable.

ARC_class SHALL influence separation_threshold_reference but SHALL NOT alter regulatory minimum.

13.4 SAIL Level

SAIL_level SHALL represent integrity and assurance level of operation.

SAIL_level SHALL determine:

Required telemetry update frequency.
Redundancy requirements.
Tactical advisory escalation thresholds.
Audit strictness requirements.

Higher SAIL SHALL NOT reduce safety threshold.

13.5 GroundRiskClass

GroundRiskClass SHALL represent population exposure risk.

GroundRiskClass SHALL be derived from:

Population density dataset.
Operational altitude.
Mission classification.

GroundRiskClass SHALL:

Influence Policy ordering if enabled.
Influence emergency escalation sensitivity.
Remain deterministic.

13.6 Operational Safety Objectives (OSO)

OSO SHALL define safety constraints applicable to mission.

OSO MAY include:

Detect-and-avoid capability requirement.
Communication redundancy requirement.
Pilot oversight requirement.
Swarm topology constraint.
Maximum wind tolerance constraint.

Violation of OSO SHALL trigger Compliance event.

13.7 Separation Threshold Binding

Risk module SHALL reference separation_threshold_reference.

Separation thresholds SHALL:

Be regulator-defined.
Be versioned.
Be immutable during negotiation.
Be enforced by Tactical.

Policy SHALL NOT configure separation below regulatory minimum.

13.8 Swarm Risk Aggregation

If swarm_flag \= true:

Risk module SHALL assign swarm_risk_id.

swarm_risk_id SHALL consider:

swarm_size
swarm_topology_type
altitude band
mission classification

Swarm risk SHALL NOT reduce individual aircraft safety requirement.

13.9 Risk Dataset Integrity

All datasets used for ARC and GroundRiskClass SHALL:

Be versioned.
Be cryptographically hashed.
Be signed by issuing authority.
Be audit-anchored upon update.

If dataset integrity verification fails:

System SHALL enter degraded mode.

13.10 Policy Integration

ArbitrationPolicy MAY reference:

ARC_class
SAIL_level
GroundRiskClass
OSO flags

RiskClass SHALL serve as deterministic input only.

Risk module SHALL NOT determine arbitration outcome.

13.11 Tactical Integration

Tactical SHALL use RiskClass to:

Determine separation threshold.
Determine advisory escalation level.
Determine reroute feasibility.

Tactical SHALL NOT modify RiskClass.

13.12 Emergency Interaction

EmergencyAirspaceDirective MAY require temporary Risk override.

Override SHALL:

Generate new RiskClass version.
Be time-bounded.
Be audit-anchored.
Preserve regulatory minimum separation.

Emergency override SHALL NOT retroactively alter completed arbitration.

13.13 Risk Lifecycle

Creation

Assigned during Planning.

Update

Version increment required.
AuditRecord required.

Expiry

Expired RiskClass SHALL NOT be used for new negotiation.

13.14 Degraded Mode Handling

If Risk dataset unavailable:

No new RiskClass SHALL be assigned.
New flight submissions MAY be restricted.
Active flights SHALL maintain last valid separation thresholds.

Degraded mode SHALL be audit-anchored.

13.15 Performance Requirements

Risk evaluation SHALL complete within:

1000 milliseconds per flight.

Bulk risk recomputation SHALL NOT block Tactical operations.

13.16 Audit Requirements

The following SHALL generate AuditRecord:

RiskClass creation.
RiskClass update.
Dataset update.
Separation threshold update.
Emergency override.
Swarm risk aggregation.

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

13.17 Certification Requirements

Certification SHALL verify:

Deterministic ARC classification.
Deterministic GroundRiskClass assignment.
SAIL integrity enforcement.
Separation threshold compliance.
Swarm risk aggregation correctness.
Dataset integrity verification.
Emergency override stability.
Performance bounds compliance.

Identical dataset and inputs SHALL produce identical RiskClass.

13.18 Non-Responsibilities

Risk SHALL NOT:

Execute negotiation.
Compute dynamic reroutes.
Override ArbitrationPolicy.
Modify Identity records.
Delete historical audit records.
Reduce regulatory separation minima.

14 NIDSP-Swarm v1.0

Coordinated Group Operations Governance

14.1 Scope

The Swarm module SHALL define the abstraction, lifecycle, negotiation handling, risk integration, and safety constraints governing grouped unmanned aircraft operations.

The Swarm module SHALL:

Define swarm identity structure.
Define swarm topology model.
Define shared operational envelope abstraction.
Define intra-swarm separation constraints.
Define coordinated negotiation behavior.
Integrate with Risk, Tactical, Infrastructure, Identity, and Core modules.
Anchor all swarm state transitions in audit chain.

The Swarm module SHALL NOT:

Override ArbitrationPolicy.
Reduce regulatory separation minima.
Modify RiskClass.
Perform trajectory optimization.
Bypass Tactical escalation.
Delete historical audit records.

14.2 Swarm Identifier Model

Each swarm SHALL be assigned:

swarm_id (UUID)
lead_operator_identity_id
participating_identity_ids
swarm_size
swarm_topology_type
swarm_risk_id
creation_timestamp
version
digital_signature

swarm_id SHALL remain immutable for duration of swarm lifecycle.

14.3 Swarm Topology Classification

Swarm SHALL declare swarm_topology_type.

Permitted topology classifications MAY include:

FORMATION_FIXED
FORMATION_DYNAMIC
HUB_AND_SPOKE
DISTRIBUTED_CLUSTER

Topology classification SHALL influence:

Intra-swarm separation requirement
Tactical reroute feasibility
Swarm risk aggregation

Topology SHALL NOT alter separation requirement relative to external traffic.

14.4 Shared Operational Envelope

Swarm SHALL define shared_operational_volume including:

3D geographic boundary
altitude_range
time_window
contingency_buffer

Individual aircraft OperationalVolume SHALL remain individually registered.

shared_operational_volume SHALL NOT exceed AuthorizationScope of any participating identity.

Violation SHALL trigger Compliance event.

14.5 Intra-Swarm Separation

Swarm SHALL define intra_swarm_separation_minimum.

intra_swarm_separation_minimum SHALL:

Be regulator-approved.
Be greater than zero.
Not violate detect-and-avoid requirements.

Tactical SHALL monitor intra-swarm compliance.

Persistent violation SHALL escalate to Core.

14.6 Swarm Risk Integration

Risk module SHALL assign swarm_risk_id.

swarm_risk_id SHALL consider:

swarm_size
topology_type
altitude_band
mission_classification

Swarm risk SHALL NOT reduce individual aircraft separation from external traffic.

14.7 Coordinated Negotiation Mode

If swarm_flag \= true:

Core SHALL treat swarm as grouped negotiation entity.

NegotiationEnvelope SHALL reference:

swarm_id
swarm_size
swarm_risk_id

Arbitration outcome SHALL apply uniformly to all swarm members.

Partial arbitration SHALL NOT occur unless explicitly permitted by Policy.

14.8 Swarm Arbitration Compression

If multiple swarms intersect:

Core SHALL activate Swarm Arbitration Compression Mode.

Compression SHALL:

Aggregate intersecting swarms into cluster.
Produce single deterministic outcome.
Preserve intra-swarm separation.

Compression SHALL NOT alter Policy ordering logic.

14.9 Swarm Split Handling

Swarm MAY split under:

Tactical reroute necessity
Emergency directive
Operator request

Split SHALL:

Generate new swarm_id.
Generate new swarm_risk_id.
Preserve audit continuity.
Trigger revalidation through Planning if required.

Split SHALL NOT bypass arbitration.

14.10 Swarm Dissolution

Swarm SHALL dissolve when:

Mission complete.
Emergency directive mandates dissolution.
Operator terminates grouped operation.

Dissolution SHALL:

Mark swarm_id inactive.
Preserve historical records.
Maintain individual aircraft identity continuity.

14.11 Infrastructure Interaction

Swarm SHALL:

Respect DroneCorridor boundaries.
Respect DronePort capacity.
Respect ReservedVolume restrictions.
Respect TemporaryInfrastructureZone.

Emergency override SHALL supersede normal corridor capacity.

14.12 Tactical Integration

Tactical SHALL:

Reference swarm_id in ConflictAlert.
Preserve swarm topology during reroute.
Enforce intra-swarm separation.
Escalate cluster conflict to Core.

DynamicReroute affecting swarm SHALL apply to all members unless split permitted.

14.13 Emergency Interaction

EmergencyAirspaceDirective SHALL:

Apply to swarm as single entity.
Preserve intra-swarm separation if feasible.
Trigger split if preservation infeasible.

Emergency override SHALL be time-bounded and audit-anchored.

14.14 Performance Requirements

System SHALL support:

Minimum 100 aircraft per swarm.
Swarm arbitration completion within same deterministic bounds as single-flight arbitration.
Swarm conflict detection within Tactical performance thresholds.

Swarm operations SHALL NOT create exponential negotiation branching.

14.15 Audit Requirements

The following SHALL generate AuditRecord:

Swarm creation.
Swarm modification.
Swarm size change.
Swarm split.
Swarm dissolution.
Swarm arbitration outcome.
Swarm compression activation.

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

14.16 Certification Requirements

Certification SHALL validate:

Deterministic swarm arbitration.
Swarm compression correctness.
Intra-swarm separation enforcement.
Risk aggregation correctness.
Tactical reroute stability.
Emergency split handling.
Performance bounds compliance.

High-density swarm stress simulation SHALL be mandatory.

14.17 Non-Responsibilities

Swarm SHALL NOT:

Compute formation geometry.
Execute autonomous flight logic.
Modify ArbitrationPolicy.
Reduce separation thresholds.
Override Emergency precedence.
Delete historical records.

15 NIDSP-Infrastructure v1.0

Persistent Airspace and Operational Object Governance

15.1 Scope

The Infrastructure module SHALL define the structure, lifecycle, priority classification, capacity management, and governance of persistent airspace and ground-linked operational objects within the NIDSP ecosystem.

The Infrastructure module SHALL:

Define DroneCorridor object.
Define DronePort object.
Define ReservedVolume object.
Define TemporaryInfrastructureZone object.
Define priority classification and capacity management.
Integrate with Planning, Tactical, Risk, Core, and Emergency modules.
Anchor infrastructure events in the audit chain.

The Infrastructure module SHALL NOT:

Execute arbitration.
Modify RiskClass.
Override ArbitrationPolicy.
Grant automatic flight permission.
Reduce regulatory separation thresholds.
Delete historical records.

15.2 Infrastructure Object Categories

The following infrastructure object categories SHALL be recognized:

DroneCorridor
DronePort
ReservedVolume
TemporaryInfrastructureZone

Each SHALL possess:

infrastructure_id (UUID, immutable)
operator_identity_id
version
digital_signature

All objects SHALL be registered in Registry.

15.3 DroneCorridor

15.3.1 Definition

DroneCorridor SHALL represent structured, persistent 3D airspace lane.

DroneCorridor SHALL include:

infrastructure_id
3D geometric boundary
altitude_range
time_validity (optional)
corridor_class
priority_class
capacity_limit
risk_reference (optional)
dataset_version_reference
digital_signature

15.3.2 Corridor Class

corridor_class MAY include:

PUBLIC
RESTRICTED
CRITICAL_INFRA

corridor_class SHALL influence Policy input if configured.

15.3.3 Capacity Management

capacity_limit SHALL define maximum concurrent flights.

Exceeding capacity SHALL:

Trigger Tactical advisory.
Trigger escalation if unresolved.
NOT allow automatic bypass unless Emergency override active.

15.4 DronePort

15.4.1 Definition

DronePort SHALL represent takeoff/landing facility.

DronePort SHALL include:

infrastructure_id
geographic_point
elevation
operational_radius
capacity_limit
occupancy_state
operator_identity_id
digital_signature

15.4.2 Occupancy Management

occupancy_state SHALL be updated in real time via Tactical.

Occupancy update latency SHALL not exceed performance bounds.

Emergency override SHALL supersede capacity limit.

15.5 ReservedVolume

ReservedVolume SHALL represent exclusive airspace allocation.

ReservedVolume SHALL include:

infrastructure_id
3D boundary
time_window
reserving_identity_id
priority_class
risk_reference (optional)
digital_signature

Overlapping ReservedVolume conflicts SHALL escalate to Core.

ReservedVolume SHALL NOT automatically win arbitration unless Policy defines priority rule.

15.6 TemporaryInfrastructureZone

TemporaryInfrastructureZone SHALL represent short-duration restriction.

TemporaryInfrastructureZone SHALL:

Be time-bounded.
Be signed.
Be audit-anchored.
Integrate with Emergency if applicable.

Expired zones SHALL automatically deactivate.

15.7 Priority Classification

priority_class SHALL be structured enumeration:

NORMAL
HIGH
CRITICAL
EMERGENCY

Policy MAY reference priority_class as deterministic input.

Emergency override SHALL supersede other classes.

15.8 Infrastructure Lifecycle

Creation

Infrastructure SHALL be created by authorized identity.

Creation SHALL:

Validate identity.
Register object.
Generate AuditRecord.

Modification

Modification SHALL:

Preserve infrastructure_id.
Increment version.
Generate AuditRecord.
Require digital signature.

Deactivation

Deactivation SHALL:

Preserve historical record.
Generate AuditRecord.
Prevent new planning reference.

15.9 Registry Integration

All infrastructure SHALL:

Be registered in Registry.
Be uniquely identifiable.
Be portable if operator changes (with audit continuity).

Ownership transfer SHALL generate AuditRecord.

15.10 Planning Integration

Planning SHALL validate:

Corridor alignment.
Port availability.
ReservedVolume compliance.
TemporaryInfrastructureZone restriction.

Violation SHALL trigger negotiation.

Infrastructure SHALL NOT grant automatic approval.

15.11 Tactical Integration

Tactical SHALL:

Validate corridor adherence.
Enforce capacity limits.
Detect encroachment into ReservedVolume.
Detect entry into TemporaryInfrastructureZone.
Escalate persistent violation to Core.

15.12 Risk Integration

Infrastructure MAY reference RiskClass.

Infrastructure SHALL NOT reduce minimum separation threshold.

Infrastructure SHALL NOT override Risk dataset.

15.13 Emergency Interaction

EmergencyAirspaceDirective MAY:

Create TemporaryInfrastructureZone.
Override capacity_limit.
Override priority_class.
Suspend corridor usage.

Emergency override SHALL be time-bounded and audit-anchored.

15.14 Surge Mode Interaction

During Surge Prioritization Mode:

Infrastructure capacity SHALL prioritize:

Emergency flights
High RiskClass flights
Swarm operations
Standard operations

Surge enforcement SHALL be deterministic.

15.15 Performance Requirements

Infrastructure validation SHALL complete within:

1000 milliseconds under nominal load.

Occupancy update SHALL complete within:

500 milliseconds.

System SHALL scale to national corridor density.

15.16 Audit Requirements

The following SHALL generate AuditRecord:

Infrastructure creation
Modification
Deactivation
Ownership transfer
Capacity violation
Emergency injection
Surge prioritization activation

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

15.17 Certification Requirements

Certification SHALL validate:

Geometry correctness
Deterministic capacity enforcement
Registry linkage integrity
Policy integration stability
Emergency override correctness
Surge prioritization behavior
Performance compliance under load

High-density corridor simulation SHALL be mandatory.

15.18 Non-Responsibilities

Infrastructure SHALL NOT:

Execute arbitration.
Compute trajectory optimization.
Modify RiskClass.
Override ArbitrationPolicy.
Issue flight permission.
Delete historical audit records.

16 NIDSP-Emergency v1.0

Sovereign Emergency Override and ATC Coordination Governance

16.1 Scope

The Emergency module SHALL define the structured governance of sovereign airspace override, temporary restriction injection, emergency prioritization, and ATC coordination within the NIDSP architecture.

The Emergency module SHALL:

Define EmergencyAirspaceDirective object.
Define emergency classifications.
Define deterministic precedence rules.
Define priority override behavior.
Define negotiation freeze behavior.
Integrate with Core, Tactical, Risk, Planning, and Infrastructure modules.
Anchor all emergency actions in the audit chain.

The Emergency module SHALL NOT:

Permanently alter ArbitrationPolicy.
Bypass Identity validation.
Reduce regulatory separation minima.
Delete historical records.
Introduce non-deterministic behavior.

16.2 EmergencyAirspaceDirective Object

EmergencyAirspaceDirective SHALL include:

emergency_id (UUID)
issuing_authority_identity_id
affected_geometry (3D boundary)
altitude_range
effective_start_time
effective_end_time
emergency_class
priority_override_flag
enforcement_level
justification_code
version
digital_signature

Unsigned directives SHALL be rejected.

Directive SHALL be cryptographically verifiable under sovereign Root CA.

16.3 Emergency Classification

emergency_class SHALL be structured enumeration:

NATIONAL_SECURITY
NATURAL_DISASTER
PUBLIC_SAFETY
AIRSPACE_INCIDENT
ATC_OVERRIDE

Classification SHALL influence enforcement behavior.

16.4 Deterministic Precedence Rule

If multiple EmergencyAirspaceDirectives overlap:

Precedence SHALL be determined by:

Issuer hierarchy rank
emergency_class priority
Effective_start_time (earliest prevails)

Precedence rules SHALL be versioned and public.

No undefined conflict state SHALL exist.

16.5 Priority Override Behavior

If priority_override_flag \= true:

Policy SHALL elevate affected flights to highest arbitration tier.

Non-emergency flights MAY be:

Rerouted
Suspended
Denied entry

Priority override SHALL:

Be time-bounded.
Preserve deterministic ordering.
Not modify completed arbitration outcomes retroactively.

16.6 Negotiation Freeze Window

Upon emergency affecting active negotiation:

Core SHALL:

Freeze affected sessions.
Capture immutable state snapshot.
Re-evaluate deterministically using updated Policy input.

Freeze duration SHALL comply with performance bounds.

16.7 Enforcement Levels

enforcement_level SHALL be structured enumeration:

ADVISORY_ONLY
MANDATORY_COMPLIANCE
IMMEDIATE_TERMINATION

ADVISORY_ONLY

Tactical SHALL issue advisory only.

MANDATORY_COMPLIANCE

Tactical SHALL issue DIRECTIVE advisory.

IMMEDIATE_TERMINATION

Tactical SHALL suspend operation in affected region and escalate to Core.

Enforcement SHALL remain proportional to emergency_class.

16.8 Temporary Infrastructure Injection

EmergencyAirspaceDirective MAY create TemporaryInfrastructureZone.

TemporaryInfrastructureZone SHALL:

Override corridor capacity.
Override ReservedVolume priority.
Be time-bounded.
Be audit-anchored.

Expired directives SHALL automatically deactivate.

16.9 Risk Interaction

Emergency MAY trigger temporary RiskClass override.

Override SHALL:

Generate new RiskClass version.
Preserve minimum separation threshold.
Be time-bounded.
Be audit-anchored.

Emergency SHALL NOT reduce safety below regulatory minimum.

16.10 Tactical Integration

Tactical SHALL:

Validate compliance in real time.
Issue DIRECTIVE advisory when violation occurs.
Escalate persistent non-compliance to Core.
Preserve separation minima during reroute.

Emergency enforcement SHALL comply with precedence rule.

16.11 ATC Coordination Interface

ATC SHALL be treated as authorized emergency issuer.

ATC-issued directives SHALL:

Include issuing authority identifier.
Be signed under sovereign Root CA.
Be audit-anchored.

ATC interface SHALL NOT execute arbitration logic.

16.12 Emergency Lifecycle

Activation

Activation SHALL:

Generate AuditRecord.
Propagate to all UTMSPs.
Freeze affected negotiations if required.

Propagation SHALL comply with performance norms.

Update

Update SHALL:

Increment version.
Preserve emergency_id.
Generate AuditRecord.

Deactivation

Deactivation SHALL:

Restore normal Policy ordering.
Preserve audit continuity.
Generate AuditRecord.

16.13 Surge Interaction

During Surge Prioritization Mode:

Emergency flights SHALL remain highest priority.

Surge mode SHALL NOT override emergency precedence.

16.14 Degraded Mode Handling

If Emergency module partially unavailable:

Existing directives SHALL remain enforceable.
New directives SHALL require verification.
Core arbitration SHALL not proceed without valid directive integrity.

Degraded state SHALL generate AuditRecord.

16.15 Performance Requirements

Emergency directive propagation SHALL complete within:

3000 milliseconds nationally under certified load.

Negotiation freeze SHALL activate within:

2000 milliseconds.

16.16 Audit Requirements

The following SHALL generate AuditRecord:

Directive issuance
Directive update
Directive deactivation
Precedence resolution
Negotiation freeze activation
Emergency-triggered arbitration
Risk override
Enforcement escalation

Audit records SHALL be hash-linked.

Deletion SHALL NOT be permitted.

16.17 Certification Requirements

Certification SHALL validate:

Directive signature validation.
Precedence rule correctness.
Freeze window behavior.
Risk override correctness.
Tactical enforcement stability.
Storm and surge interaction.
Partition safety.
Performance compliance under emergency load.

Large-scale emergency simulation SHALL be mandatory.

16.18 Non-Responsibilities

Emergency SHALL NOT:

Permanently modify ArbitrationPolicy.
Bypass Identity validation.
Reduce separation minima.
Modify Infrastructure geometry outside TemporaryInfrastructureZone.
Delete historical records.

17 Security Requirements

Cryptographic Trust, Authentication, and Integrity Governance

17.1 Scope

This section defines the cryptographic, authentication, message integrity, replay protection, and trust governance requirements applicable to all NIDSP modules.

Security SHALL ensure:

Authenticity of actors
Integrity of data exchange
Non-repudiation of critical actions
Deterministic validation behavior
Protection against replay and impersonation
Protection against unauthorized modification

Security SHALL apply uniformly across:

Identity
Registry
Planning
Tactical
Core
Risk
Swarm
Infrastructure
Emergency

17.2 Sovereign Root Certificate Authority

All certificates used within NIDSP SHALL chain to a sovereign Root Certificate Authority (Root CA).

Root CA SHALL:

Be regulator-controlled.
Be securely maintained.
Publish certificate revocation information.
Support certificate lifecycle governance.

No external trust anchor SHALL be permitted without regulator approval.

17.3 X.509 Certificate Requirements

All participating entities SHALL use X.509 certificates.

Certificates SHALL:

Include organization identifier.
Include jurisdiction identifier.
Include role classification.
Include validity period.
Be revocable.
Be uniquely identifiable.

Certificates SHALL be validated prior to:

Telemetry acceptance.
NegotiationEnvelope processing.
Infrastructure creation.
Emergency directive issuance.

17.4 Mutual TLS (mTLS)

All inter-UTMSP communication SHALL use mutual TLS.

mTLS SHALL:

Authenticate both client and server.
Validate certificate chain.
Enforce encryption of data in transit.
Prevent unauthorized connection.

Unencrypted communication SHALL be prohibited.

17.5 Digital Signature Requirements

All state-changing messages SHALL be digitally signed.

This includes:

NegotiationEnvelope
TelemetryObject
ConflictAlert
DynamicReroute
RiskClass assignment
EmergencyAirspaceDirective
Infrastructure modification
Identity update
Policy update

Signature SHALL:

Be verifiable against certificate.
Use regulator-approved cryptographic algorithm.
Fail deterministically if invalid.

17.6 Message Integrity

All messages SHALL include:

Timestamp
Unique message_id
Nonce (where applicable)
Digital signature

Tampered message SHALL be rejected.

Integrity verification SHALL occur prior to processing.

17.7 Replay Protection

Replay protection SHALL include:

Nonce uniqueness enforcement.
message_id uniqueness enforcement.
Timestamp expiration validation.
Duplicate detection.

Replay attempt SHALL:

Be rejected.
Generate AuditRecord.
Trigger Compliance notification if persistent.

17.8 Revocation Enforcement

Revoked certificates SHALL:

Be rejected immediately.
Prevent further participation in negotiation.
Prevent telemetry processing.
Prevent directive issuance.

Revocation status SHALL be checked within defined performance bounds.

Revocation propagation SHALL comply with performance requirements.

17.9 Deterministic Validation Behavior

Security validation SHALL:

Produce identical accept/reject decision for identical inputs.
Not depend on runtime randomness.
Not depend on system load.
Be version-consistent across UTMSPs.

17.10 Data at Rest Protection

Sensitive data SHALL:

Be stored with integrity protection.
Be version-controlled.
Be protected against unauthorized modification.
Be audit-traceable.

Critical modules SHALL implement strong authentication for update operations.

17.11 Risk Dataset Protection

Risk datasets SHALL:

Be cryptographically hashed.
Be versioned.
Be signed by issuing authority.
Be validated prior to use.

Dataset corruption SHALL trigger degraded mode.

17.12 Policy Integrity

ArbitrationPolicy SHALL:

Be digitally signed.
Be hash-anchored.
Be versioned.
Be publicly verifiable.

Policy tampering SHALL invalidate negotiation session.

17.13 Audit Chain Integrity

AuditRecord SHALL:

Include hash_of_previous_record.
Form immutable hash-linked chain.
Be tamper-evident.

Audit modification SHALL be detectable.

Deletion SHALL NOT be permitted.

17.14 Compromise Handling

If security compromise detected:

Affected identity SHALL be suspended.
Certificates SHALL be revoked.
Emergency override MAY be activated.
Compliance Authority SHALL be notified.
AuditRecord SHALL be generated.

System SHALL maintain deterministic behavior during compromise containment.

17.15 Partition and Recovery Security

During network partition:

Independent arbitration SHALL NOT occur.
Cached certificates SHALL be validated against last known revocation list.
Reconciliation SHALL occur upon reconnection.

Security SHALL preserve audit integrity during partition.

17.16 Performance Requirements

Certificate validation SHALL complete within:

500 milliseconds.

Revocation check SHALL complete within:

1000 milliseconds.

Signature verification SHALL complete within:

500 milliseconds.

Security validation SHALL NOT exceed Tactical latency thresholds.

17.17 Certification Requirements

Certification SHALL verify:

Certificate chain validation.
mTLS enforcement.
Signature correctness.
Replay protection correctness.
Revocation propagation.
Audit integrity.
Partition safety.
Deterministic validation under load.

Security stress simulation SHALL be mandatory.

17.18 Non-Responsibilities

Security framework SHALL NOT:

Execute arbitration.
Modify RiskClass.
Override ArbitrationPolicy.
Modify Infrastructure geometry.
Delete audit records.
Introduce non-deterministic behavior.

18 Performance & Scalability Requirements

Latency, Throughput, Availability, and Resilience Governance

18.1 Scope

This section defines mandatory performance, scalability, availability, and resilience requirements applicable to all NIDSP modules.

Performance SHALL ensure:

Safety preservation under load.
Deterministic arbitration stability.
Timely emergency propagation.
Scalable national deployment.
Bounded degraded behavior.

These requirements SHALL be certifiable.

18.2 General Principles

Increased load SHALL NOT alter arbitration outcome.
Performance degradation SHALL fail safely.
Safety SHALL take precedence over availability.
Performance metrics SHALL be measurable and auditable.
Load SHALL NOT introduce non-determinism.

18.3 Latency Requirements

18.3.1 Telemetry Processing

End-to-end telemetry validation SHALL NOT exceed:

500 milliseconds under nominal load.
1000 milliseconds under certified peak load.

18.3.2 ConflictAlert Propagation

ConflictAlert exchange between UTMSPs SHALL NOT exceed:

1000 milliseconds under nominal load.

18.3.3 Escalation to Core

Tactical escalation to Core SHALL NOT exceed:

2000 milliseconds from conflict detection.

18.3.4 Arbitration Completion

Arbitration SHALL complete within:

Configured maximum bound defined in ArbitrationPolicy.
Not exceed 10 seconds per negotiation session unless emergency freeze active.

18.3.5 Emergency Directive Propagation

EmergencyAirspaceDirective SHALL propagate nationally within:

3000 milliseconds under certified peak load.

18.3.6 Negotiation Freeze Activation

Emergency freeze window SHALL activate within:

2000 milliseconds of directive receipt.

18.4 Throughput Requirements

Each certified UTMSP SHALL support:

Minimum 10,000 concurrent active telemetry streams.

National system SHALL support:

Minimum 100,000 concurrent active flights.

Throughput increase SHALL NOT degrade deterministic ordering.

18.5 Swarm Scalability

System SHALL support:

Minimum 100 aircraft per swarm.

Swarm arbitration SHALL complete within same deterministic bounds as single-flight arbitration.

Swarm conflict detection SHALL not cause exponential negotiation branching.

18.6 Infrastructure Capacity Handling

Infrastructure validation SHALL complete within:

1000 milliseconds per planning request.

DronePort occupancy update SHALL complete within:

500 milliseconds.

Capacity exceedance advisory SHALL be generated within:

1000 milliseconds.

18.7 Risk Evaluation Performance

RiskClass assignment SHALL complete within:

1000 milliseconds per flight.

Bulk risk recomputation SHALL NOT block Tactical or Core operations.

18.8 Identity & Security Validation Performance

Certificate validation SHALL complete within:

500 milliseconds.

Revocation status verification SHALL complete within:

1000 milliseconds.

Signature verification SHALL complete within:

500 milliseconds.

Security validation SHALL not exceed Tactical latency bounds.

18.9 Availability Requirements

Core SHALL maintain:

Minimum 99.95% uptime per calendar month.

Tactical SHALL maintain:

Minimum 99.9% uptime per calendar month.

Emergency directive processing SHALL remain available during degraded network conditions.

Failover SHALL preserve audit continuity.

18.10 Resilience Requirements

System SHALL tolerate:

Single-node failure.
Partial UTMSP outage.
Network partition (within defined bounds).
Load surge exceeding nominal thresholds.

During partition:

No independent arbitration SHALL occur.
Safe Holding Mode SHALL activate.
Increased separation thresholds MAY apply.

18.11 Surge Prioritization Mode

If system load exceeds certified threshold:

Surge Prioritization Mode SHALL activate.

Flight ordering SHALL follow:

Emergency flights
High RiskClass flights
Swarm operations
Standard operations

Surge activation SHALL:

Be audit-anchored.
Be time-bounded.
Preserve determinism.

18.12 Storm Compression Activation

If negotiation storm detected:

Storm Compression Mode SHALL activate.

Compression SHALL:

Cluster conflicts.
Reduce redundant negotiation cycles.
Preserve Policy ordering logic.

Storm Compression SHALL complete within defined arbitration bounds.

18.13 Degraded Mode Operation

If performance thresholds exceeded or critical dataset unavailable:

System SHALL enter Degraded Mode.

Degraded Mode SHALL:

Restrict new non-critical flight submissions.
Preserve active flight safety.
Maintain separation thresholds.
Prevent arbitration with incomplete data.
Preserve emergency enforcement capability.

Degraded Mode SHALL generate AuditRecord.

18.14 Deterministic Message Ordering

Message ordering SHALL:

Remain stable under load.
Be preserved during failover.
Be idempotent.
Be replay-resistant.

Load balancing SHALL NOT alter message ordering semantics.

18.15 Failover Requirements

Failover SHALL:

Preserve negotiation state.
Preserve audit chain continuity.
Prevent duplicate arbitration.
Prevent divergent resolution.

Recovery SHALL reconcile against last valid audit snapshot.

18.16 Monitoring Requirements

System SHALL continuously monitor:

Telemetry latency.
ConflictAlert latency.
Escalation timing.
Arbitration duration.
Emergency propagation timing.
Rate limiting events.
Surge activation events.
Partition detection.

Monitoring data SHALL be audit-anchored.

18.17 Certification Requirements

Certification SHALL include:

High-density traffic simulation.
Multi-swarm stress simulation.
Emergency injection under load.
Negotiation storm simulation.
Partition simulation.
Surge simulation.
Replay flood simulation.
Failover recovery simulation.

Certification SHALL verify:

Latency compliance.
Throughput compliance.
Deterministic behavior.
Safety preservation.
Audit integrity.

18.18 Non-Responsibilities

Performance requirements SHALL NOT mandate:

Specific cloud provider.
Specific database implementation.
Specific hardware architecture.
Specific programming language.

Implementation SHALL meet requirements irrespective of technology choice.

19 Operational Hardening & Extreme Condition Safeguards

Deterministic Stability Under Adverse Conditions

19.1 Scope

This section defines mandatory safeguards applicable during:

High-density traffic conditions
Multi-party negotiation storms
Swarm cluster conflicts
Identity compromise
Telemetry flooding
Network partition
Simultaneous emergency directives
Dataset corruption
National-scale surge events

These safeguards SHALL preserve:

Deterministic arbitration
Separation safety
Sovereign override integrity
Audit continuity
System stability

19.2 Negotiation Storm Compression

If the number of intersecting negotiations exceeds storm_compression_threshold defined in ArbitrationPolicy:

Core SHALL activate Storm Compression Mode.

Storm Compression SHALL:

Aggregate intersecting OperationalVolumes into cluster arbitration.
Reduce redundant negotiation branching.
Preserve deterministic ordering rules.
Produce single arbitration result per cluster.

Storm Compression SHALL NOT modify ArbitrationPolicy logic.

Activation SHALL generate AuditRecord.

19.3 Swarm Arbitration Compression

If multiple swarms intersect:

Core SHALL treat swarms as grouped swarm-cluster entity.

Swarm Arbitration Compression SHALL:

Prevent exponential negotiation cycles.
Preserve intra-swarm separation constraints.
Produce deterministic outcome for entire cluster.

Partial arbitration SHALL NOT occur unless explicitly enabled in Policy.

19.4 Emergency Freeze Window

Upon receipt of EmergencyAirspaceDirective with priority_override_flag \= true:

Core SHALL:

Freeze all active negotiation sessions affecting affected_geometry.
Capture immutable state snapshot.
Re-evaluate using updated Policy inputs.
Resume negotiation deterministically.

Freeze SHALL be time-bounded and audit-anchored.

19.5 Mid-Flight Identity Revocation Handling

If Identity is revoked during active operation:

Tactical SHALL:

Issue DIRECTIVE advisory immediately.
Prevent further negotiation messages.
Escalate to Core if necessary.

Core SHALL:

Block new negotiation participation.
Preserve completed arbitration outcome.

Compliance Authority SHALL be notified.

Event SHALL generate AuditRecord.

19.6 Tactical Rate Limiting

Tactical SHALL enforce:

Maximum telemetry rate per identity_id.
Maximum telemetry rate per UTMSP.
Maximum ConflictAlert generation rate.

Rate limiting SHALL:

Preserve safety-critical messages.
Prevent denial-of-service.
Preserve deterministic ordering.

Excessive rate SHALL trigger Compliance event.

19.7 Network Partition Safe Mode

If partition detected between UTMSPs or Core:

System SHALL enter Safe Holding Mode.

Safe Holding Mode SHALL:

Suspend new arbitration.
Maintain increased separation threshold.
Prevent independent arbitration.
Preserve audit continuity.

Upon reconnection:

Reconciliation SHALL occur using last valid audit snapshot.
Divergent states SHALL be rejected.

Partition entry and exit SHALL generate AuditRecord.

19.8 Emergency Directive Precedence Conflict

If overlapping EmergencyAirspaceDirectives detected:

System SHALL resolve using deterministic precedence rule defined in Section 16.

No undefined conflict state SHALL be permitted.

Precedence resolution SHALL be audit-anchored.

19.9 Risk Dataset Corruption Handling

If Risk dataset fails integrity verification:

System SHALL:

Enter Degraded Mode.
Suspend new RiskClass assignments.
Maintain existing separation thresholds.
Notify Compliance Authority.

Corruption event SHALL generate AuditRecord.

19.10 Surge Prioritization Mode

If system load exceeds certified threshold:

Surge Prioritization Mode SHALL activate.

Ordering SHALL be:

Emergency flights
High RiskClass flights
Swarm operations
Standard operations

Surge Mode SHALL:

Restrict non-critical flight injection.
Preserve safety of active flights.
Remain deterministic.
Be time-bounded.

Activation SHALL generate AuditRecord.

19.11 Degraded Mode Safety Guarantee

In Degraded Mode:

No arbitration SHALL occur without complete input dataset.
Tactical SHALL default to increased separation threshold.
Emergency SHALL remain operational.
Planning MAY restrict new non-critical operations.

Degraded Mode SHALL generate AuditRecord.

19.12 Compromise Containment

If systemic compromise suspected:

System SHALL:

Suspend affected identities.
Revoke compromised certificates.
Prevent new negotiations from affected nodes.
Escalate to Compliance Authority.

Deterministic arbitration SHALL remain intact for unaffected entities.

19.13 Failover Integrity Preservation

During failover:

Negotiation state SHALL be preserved.
Duplicate arbitration SHALL not occur.
Audit chain SHALL remain intact.
Message ordering SHALL remain deterministic.

Failover events SHALL generate AuditRecord.

19.14 Hardening Certification Requirements

Certification SHALL simulate:

Negotiation storm scenario.
Multi-swarm intersection.
Emergency injection during negotiation.
Mid-flight identity revocation.
Telemetry flood attack.
Network partition event.
Risk dataset corruption.
Surge load scenario.
Simultaneous emergency directives.

Certification SHALL verify:

Deterministic outcomes.
Safety preservation.
No undefined states.
Bounded latency.
Audit integrity continuity.

19.15 Non-Responsibilities

Operational Hardening SHALL NOT:

Alter ArbitrationPolicy logic.
Reduce regulatory safety thresholds.
Override sovereign authority.
Delete audit records.
Introduce probabilistic behavior.

20 Certification Framework

Validation, Compliance, and Continuous Conformance Governance

20.1 Scope

This section defines the mandatory certification, validation, monitoring, audit, and re-certification requirements applicable to all UTMSPs and participating entities under NIDSP 1.1.

Certification SHALL ensure:

Deterministic behavior.
Safety preservation.
Performance compliance.
Security enforcement.
Audit integrity.
Sovereign override stability.
Resilience under stress.

Participation in interoperable operations SHALL require valid certification.

20.2 Certification Authority

Certification SHALL be conducted by:

Designated Authority appointed by sovereign regulator.
Or regulator-approved independent conformity body.

Certification Authority SHALL:

Issue conformance certificate.
Maintain registry of certified UTMSPs.
Publish certification status.
Define certification validity period.

20.3 Certification Scope

Certification SHALL cover:

Core negotiation engine
ArbitrationPolicy integration
Identity validation
Registry integrity
Planning validation
Tactical real-time coordination
Risk classification integrity
Swarm governance
Infrastructure compliance
Emergency override handling
Security enforcement
Performance compliance
Operational hardening behavior

Partial certification SHALL NOT permit interoperability participation.

20.4 Deterministic Validation Testing

Certification SHALL include identical-input replay testing.

Given identical:

Risk dataset version
Policy version
Identity records
Infrastructure state
Negotiation snapshot

System SHALL produce identical arbitration outcome.

Deviation SHALL result in certification failure.

20.5 Performance Validation Testing

Certification SHALL validate:

Telemetry latency compliance
ConflictAlert propagation timing
Escalation timing
Arbitration completion timing
Emergency propagation timing
Surge activation timing
Partition recovery timing

Testing SHALL include peak-load simulation.

Failure to meet latency bounds SHALL result in certification denial.

20.6 Stress & Resilience Simulation

Mandatory simulation scenarios SHALL include:

Negotiation storm event
Multi-swarm cluster conflict
Emergency directive injection mid-negotiation
Simultaneous emergency directive conflict
Network partition event
Telemetry flood attack
Identity revocation mid-flight
Risk dataset corruption
Surge load beyond nominal capacity
Failover and recovery event

System SHALL preserve safety and determinism in all scenarios.

20.7 Security Conformance Testing

Security certification SHALL verify:

Certificate chain validation
mTLS enforcement
Signature verification correctness
Replay protection enforcement
Revocation propagation timing
Audit tamper detection
Compromise containment procedure

Penetration testing SHALL be mandatory.

20.8 Audit Integrity Validation

Certification SHALL verify:

Hash-linked audit chain
Tamper-evidence detection
Complete state transition coverage
No deletion of historical records
Proper signature validation of audit entries

Audit continuity SHALL be tested across failover events.

20.9 Continuous Monitoring Requirements

Certified UTMSPs SHALL implement continuous monitoring of:

Latency metrics
Arbitration duration
Emergency propagation timing
Rate limit events
Surge activation
Partition detection
Revocation enforcement
Dataset integrity checks

Monitoring data SHALL be auditable.

Significant deviation SHALL trigger compliance review.

20.10 Re-Certification Requirements

Re-certification SHALL be required upon:

Major software upgrade affecting Core, Policy, or Security.
Change in ArbitrationPolicy logic.
Change in Risk dataset processing logic.
Infrastructure model modification.
Security architecture modification.

Minor patching SHALL require declaration and audit.

Certification validity SHALL be time-limited.

20.11 Compliance Violations

If certified entity violates specification:

Certification Authority MAY:

Issue warning.
Impose corrective action plan.
Suspend certification.
Revoke certification.

Revocation SHALL:

Be published.
Be audit-anchored.
Immediately suspend interoperability participation.

20.12 Interoperability Testing

All certified UTMSPs SHALL participate in:

Cross-UTMSP interoperability simulation.
Cross-arbitration deterministic replay validation.
Swarm coordination testing.
Emergency propagation test.

Interoperability SHALL be validated prior to operational launch.

20.13 Transparency & Reporting

Certification Authority SHALL publish:

List of certified entities.
Certification validity dates.
Revocation notices.
Major compliance actions.

Sensitive implementation details SHALL remain protected.

20.14 Change Management Governance

Specification updates SHALL:

Be versioned.
Be publicly published.
Include change summary.
Require transition plan.
Define compatibility window.

Backward compatibility SHALL be defined where feasible.

Migration SHALL NOT compromise safety or determinism.

20.15 Non-Responsibilities

Certification framework SHALL NOT:

Mandate specific technology vendor.
Mandate specific cloud provider.
Mandate specific programming language.
Modify ArbitrationPolicy.
Override sovereign authority.
Delete audit records.

ANNEXURE A — Data Object Schemas (Normative)

A.1 General Requirements

All objects defined in this annexure SHALL:

Be JSON-serializable.
Be UTF-8 encoded.
Use ISO 8601 UTC timestamps.
Include digital_signature where state-changing.
Enforce strict schema validation.
Reject unknown mandatory field omissions.

A.2 NegotiationEnvelope Schema

Mandatory Fields:

envelope_id (UUID)
negotiation_id (UUID)
originating_utms_id (UUID)
target_utms_id (UUID)
flight_ids (Array\<UUID>)
swarm_id (UUID, optional)
operational_volume_hash (SHA-256 string)
proposal_payload_hash (SHA-256 string)
round_number (Integer ≥ 0)
timestamp (ISO 8601 UTC)
nonce (String, unique per sender)
digital_signature (Base64 string)

Validation Rules:

envelope_id MUST be unique.
round_number MUST increment deterministically.
timestamp MUST not exceed replay window threshold.
digital_signature MUST verify under sender certificate.

A.3 TelemetryObject Schema

Mandatory Fields:

flight_id (UUID)
UIN (String)
identity_id (UUID)
latitude (Float)
longitude (Float)
altitude (Float)
velocity_vector (Vector3)
heading (Float)
timestamp (ISO 8601 UTC)
confidence_indicator (Float 0–1)
nonce (String)
digital_signature

Validation Rules:

Timestamp staleness MUST not exceed telemetry_staleness_threshold.
Nonce MUST be unique per identity_id.
UIN MUST exist in Registry.

A.4 ConflictAlert Schema

Mandatory Fields:

alert_id (UUID)
originating_utms_id
target_utms_id
flight_ids_involved
swarm_id (optional)
predicted_intersection_volume
time_window
separation_distance_estimate
risk_level (ENUM)
advisory_level (ENUM)
timestamp
digital_signature

A.5 RiskClass Schema

Mandatory Fields:

risk_id (UUID)
flight_id
ARC_class (ENUM)
SAIL_level (ENUM)
GroundRiskClass (ENUM)
OperationalSafetyObjectives (Array)
separation_threshold_reference
swarm_risk_flag (Boolean)
effective_time_window
dataset_version_reference
digital_signature

A.6 EmergencyAirspaceDirective Schema

Mandatory Fields:

emergency_id (UUID)
issuing_authority_identity_id
affected_geometry
altitude_range
effective_start_time
effective_end_time
emergency_class (ENUM)
priority_override_flag (Boolean)
enforcement_level (ENUM)
justification_code
digital_signature

A.7 AuditRecord Schema

Mandatory Fields:

audit_id (UUID)
module_origin
event_type
object_reference
timestamp
hash_of_previous_record
digital_signature

AuditRecord SHALL form hash-linked chain.

ANNEXURE B — State Machine Definitions (Normative)

B.1 Core Negotiation State Machine

States:

INITIATED
NEGOTIATING
CONVERGED
ESCALATED
ARBITRATION_PENDING
RESOLUTION_FINALIZED
DEADLOCK

Transitions SHALL be deterministic.

Illegal transitions SHALL be rejected.

B.2 Planning State Model

SUBMITTED → VALIDATED → NEGOTIATION_PENDING → APPROVED
SUBMITTED → DENIED
APPROVED → SUSPENDED

B.3 Tactical Advisory Escalation Model

INFORMATIVE → SUGGESTIVE → DIRECTIVE → ESCALATED

DIRECTIVE SHALL precede escalation unless separation threshold breached immediately.

B.4 Emergency Lifecycle

CREATED → ACTIVE → UPDATED → EXPIRED

EXPIRED SHALL restore normal Policy ordering.

B.5 Swarm Lifecycle

CREATED → ACTIVE → SPLIT → ACTIVE → DISSOLVED

Each split SHALL generate new swarm_id.

ANNEXURE C — Arbitration Worked Examples (Illustrative)

Example 1: Equal Risk Flights

Inputs:

Same ARC
Same corridor class
Same timestamp

Outcome:

Ordered by UTMSP_identifier lexicographically.

Example 2: Emergency vs Normal

Inputs:

emergency_override_flag \= true for Flight A

Outcome:

Flight A ordered highest.

Example 3: Swarm vs Single

Inputs:

Swarm size \= 20
Single flight standard

If swarm_priority_rule enabled:

Swarm treated as grouped entity.
Otherwise:
Standard ordering.

ANNEXURE D — Separation Threshold Reference (Normative)

ARC Class	Minimum Horizontal Separation	Minimum Vertical Separation
ARC A	X meters	Y meters
ARC B	X+Δ	Y+Δ
ARC C	X+2Δ	Y+2Δ
ARC D	X+3Δ	Y+3Δ

Actual numeric values SHALL be regulator-defined and versioned.

Swarm intra-separation SHALL not be less than regulator minimum.

ANNEXURE E — Timing & Timeout Matrix (Normative)

Parameter	Maximum Bound
Telemetry staleness	2 seconds
Negotiation timeout	Policy-defined (≤10s default)
Arbitration completion	≤10 seconds
Emergency propagation	≤3 seconds
Freeze activation	≤2 seconds
Revocation propagation	≤1 second
Replay window	≤30 seconds

All SHALL be configurable but bounded.

ANNEXURE F — Error Codes & Compliance Events (Normative)

Code	Description	Severity
ERR_IDENTITY_REVOKED	Identity inactive	Critical
ERR_CERT_INVALID	Signature invalid	Critical
ERR_REPLAY_DETECTED	Nonce duplicate	High
ERR_CAPACITY_EXCEEDED	Corridor full	Medium
ERR_POLICY_MISMATCH	Policy version mismatch	High
ERR_RISK_DATASET_CORRUPT	Integrity failure	Critical
ERR_NEGOTIATION_TIMEOUT	Max rounds exceeded	Medium

All critical errors SHALL generate Compliance notification.

ANNEXURE G — Degraded Mode Matrix (Normative)

Condition	New Flights	Active Flights	Arbitration
Risk dataset unavailable	Restricted	Continue	Disabled
Core overload	Restricted	Continue	Deferred
Partition	Restricted	Continue	Disabled
Policy update	Restricted	Continue	Disabled

Safety SHALL remain enforced.

ANNEXURE H — Security Algorithm Requirements (Normative)

TLS 1.3 minimum
SHA-256 minimum hash
RSA-2048 or ECDSA P-256 minimum
Certificate validity ≤ 2 years
OCSP or CRL revocation mandatory
Perfect Forward Secrecy required

Algorithms SHALL be regulator-approved.

ANNEXURE I — Certification Test Catalogue (Normative)

Mandatory Tests:

Deterministic replay
Storm compression scenario
Multi-swarm arbitration
Emergency injection mid-negotiation
Identity revocation mid-flight
Telemetry flood attack
Network partition
Dataset corruption
Surge mode activation
Failover recovery

All tests SHALL pass prior to certification issuance.

ANNEXURE J — Migration & Version Governance (Normative)

J.1 Policy Version Migration

New Policy SHALL:

Include compatibility window.
Not affect active negotiation.
Be audit-anchored.

J.2 Dataset Version Migration

Risk dataset update SHALL:

Be signed.
Be versioned.
Trigger integrity validation.

J.3 Backward Compatibility

Interoperability SHALL require:

Version handshake.
Compatibility declaration.
Grace period defined by regulator.

ANNEXURE K — Spec Markdown

nidsp-sdk/
│
├── README.md
├── VERSION
│
├── spec/
│   ├── overview.md
│   ├── architecture.md
│   ├── principles.md
│   │
│   ├── core/
│   │   ├── spec.md
│   │   ├── state-machine.md
│   │   ├── openapi.yaml
│   │   └── mermaid.md
│   │
│   ├── policy/
│   ├── identity/
│   ├── registry/
│   ├── planning/
│   ├── tactical/
│   ├── risk/
│   ├── swarm/
│   ├── infrastructure/
│   ├── emergency/
│   ├── security/
│   │
│   └── annexures/
│       ├── schemas/
│       ├── timing-matrix.md
│       ├── error-codes.md
│       ├── degraded-mode.md
│       └── certification-tests.md
│
├── openapi/
│   ├── core.yaml
│   ├── policy.yaml
│   ├── identity.yaml
│   ├── registry.yaml
│   ├── planning.yaml
│   ├── tactical.yaml
│   ├── risk.yaml
│   ├── swarm.yaml
│   ├── infrastructure.yaml
│   ├── emergency.yaml
│   └── security.yaml
│
├── schemas/
│   ├── json/
│   └── protobuf/
│
├── diagrams/
│   ├── system.mmd
│   ├── negotiation-state.mmd
│   ├── emergency-flow.mmd
│   ├── swarm-flow.mmd
│   └── degraded-mode.mmd
│
├── test-vectors/
│   ├── deterministic-replay/
│   ├── storm-compression/
│   ├── swarm-arbitration/
│   ├── emergency-precedence/
│   └── partition-recovery/
│
└── sdk-guides/
    ├── implementation-guide.md
    ├── deterministic-rules.md
    ├── language-mapping.md
    └── certification-checklist.md