Application Overview Report

SAFE Prototype — Comprehensive Capability Summary

SYSE 701 Research Prototype

SAFE Prototype

Secure Adaptive Fusion Environment

A five-layer zero-knowledge proof architecture for trustless coalition sensor fusion. This report provides a comprehensive overview of the prototype's capabilities, data flows, simulation architecture, and research evidence outputs.

Version: SAFE-prototype-v2.0·Report Date: 2026-05-16·Research Question Coverage: RQ1, RQ2, RQ3, SIM

Prototype Notice: Cryptographic functions are simulated with calibrated timing. Results reflect modelled behaviour within the prototype environment, not production cryptographic execution. ZK proof generation, trusted setup, and recipient hash binding are explicitly simulated — not real cryptographic operations.

01

Architecture Overview

System components, data flow, and research question mapping

System Components

RQ1 Benchmark Engine— Streams per-track ZKP events via SSE
RQ2 Gatekeeper— Policy-score-driven fusion mode selection
RQ3 Dissemination— Bloom lineage + recipient binding policy
Enhanced Simulation— 20-min maritime ISR with 4 coalition ships
Traceability Matrix— 40+ requirement-to-artifact entries
Supabase Backend— 4 tables: tasks, proof_runs, sim_runs, sim_events

End-to-End Data Flow

1
Configure— User selects scenario, protocol, topology, sensors, seed
2
Generate— API streams SSE events (per-track JSON) from backend engine
3
Evaluate— Gatekeeper applies ZKP verification + policy scoring
4
Visualize— Charts, maps, tables, and audit logs update in real-time
5
Export— CSV, JSON, Markdown, HTML exports from current session
6
Archive— Save Run persists summary + telemetry to Supabase
7
Reference— Traceability matrix links artifacts to dissertation claims
RQ1

Can ZK-SNARKs meet tactical timing and bandwidth constraints?

RQ2

Does policy-score gatekeeper outperform proof-check baseline under adversarial conditions?

RQ3

Does recipient binding + Bloom lineage enable adequate cross-domain provenance?

SIM

How does SAFE perform in a realistic 20-minute maritime coalition ISR scenario?

02

Five-Layer ZK Protocol

Circuit design, constraint counts, and per-protocol performance

L1
Verifiable Fidelity
Range-check circuit proving sensor CEP < tier threshold without revealing RMS measurements.
512 constraints
L2
Anonymous Lineage
k=5 Poseidon hash evaluations proving Bloom filter membership without revealing sensor ID.
1,280 constraints
L3
Physics-Based Identity
Merkle inclusion proof in threat library proving target class without revealing coordinates.
2,048 constraints
L4
Freshness Binding
Timestamp arithmetic + range check proving message is within the 30-second freshness window.
384 constraints
L5
Recipient Binding
Hash comparison circuit binding sensitive fields to the authorised recipient node.
256 constraints
ProtocolProve (ms)Verify (ms)Proof SizePasses 100ms?Notes
PLONK658400 BYesUniversal SRS, recommended for production
GROTH16906200 BYesSmallest proof, per-circuit trusted setup
STARK250445 KBNoPost-quantum, no trusted setup, 45 KB proof
BULLETPROOF50050700 BNoNo trusted setup, logarithmic proof size, slow prove
Calibration note: All timing values are calibrated against published ZK-SNARK benchmark literature and include 15% jitter to model real-world hardware variance. The prototype uses a stub prover — no real circuit compilation occurs. The 100 ms prove threshold derives from a 10 Hz tactical data link update rate (one proof per 100 ms update cycle).
03

RQ1: ZKP Operational Feasibility

/rq1 — ZKP Benchmarking Engine

Configuration Inputs

Scenario type5 scenarios (Benign, Mixed Quality, Replay/Stale, Data Incest, Adversarial)
ZK protocolsPLONK, GROTH16, STARK, BULLETPROOF (multi-select)
Circuitstier_check_linear (baseline) or tier_check_norm (realistic norm-based)
Sensor typesSurface Radar, Volume Radar, EO/IR, ESM, Acoustic (multi-select)
Runs per combo1–500 (default 30). Total = protocols × sensors × runs
Identity proofsOptional Layer 3 (2048-constraint Merkle circuit) + classification level
Link conditionsNominal, Degraded, Poor — sets BER, drop rate, latency
Experiment labelHuman-readable ID for export and replay reference
Random seedExplicit seed for deterministic reproducibility

Outputs & Visualizations

Real-time feedStreamed track events with protocol, sensor, prove/verify, bytes, success flag
Protocol stats tableMean/P95 prove time, verify time, proof size vs. RQ1 thresholds
Layer breakdown chartPer-layer prove time contribution (L1–L5) per protocol
Proof bytes chartPer-layer circuit output bytes (STARK KB vs. PLONK bytes)
Activity feedChronological track log with pass/fail indicators
Bandwidth analysisLink preset effects on message loss and effective throughput
Experiment reportConfigurable HTML/Markdown report with methodology section
Historical replayRe-run any prior experiment using saved random seed
Exports: Raw CSV, Summary CSV, RQ2-feed CSV, Markdown reportPersists to: proof_runs tableKey finding: PLONK (65ms) and GROTH16 (90ms) pass 100ms threshold
04

RQ2: Adaptive Gatekeeper Architecture

/rq2 — Policy-Driven Fusion Control

Policy Score Formula

policyScore = 0.35 × norm(wFidelity) + 0.25 × norm(wLink) + 0.20 × norm(wOutlier) + 0.10 × norm(wAge) + 0.10 × norm(wLineage)
Factorα WeightGold (best)SilverBronze (worst)Measures
wFidelity0.351.01.42.0ZKP-verified sensor quality tier
wAge0.11.01.22.5Track freshness (age in seconds)
wLineage0.11.01.23.0Lineage depth + Bloom incest flag
wOutlier0.21.01.52.5Positional plausibility check
wLink0.251.01.42.0BER + drop rate + latency of data link
KALMANscore ≥0.65

Optimal Kalman fusion — high confidence track

CIscore 0.35–0.65

Covariance Intersection — conservative fusion

REJECTscore <0.35

Track rejected — does not enter fuser

Scenario Types

BenignAll partners honest, nominal link conditions. Validates baseline SAFE performance.
MixedHeterogeneous fidelity tiers and degraded links. Exercises adaptive weighting.
Replay35% of tracks are valid-but-stale replays. Tests freshness binding.
IncestFusion loops generate circular lineage. Tests Bloom filter detection.
AdversarialCombined replay + incest + proof spoof + outliers at high rate.

Key Outputs

Live feedPer-track decisions with layer L1–L5 status, policy score, CI reason
Comparison summaryBaseline vs. SAFE KALMAN/CI/REJECT rates side-by-side
Track mapGeospatial truth position + baseline estimate + SAFE estimate + error ellipse
CI reason chartPie of incest_detected, aged_track, low_fidelity_bronze, link_quality_degraded, outlier_position
RMS summaryMean/max position error per tier (Gold/Silver/Bronze) × mode (Baseline/SAFE)
Gatekeeper audit logFilterable per-track table with policyScore, topFactor, rejectReason
Policy score vizScore vs. RMS scatter, mean score by decision, weight factor bars
Fusion qualityNEES tracking, RMS trend over time
Save RunPersists to sim_runs + sim_events tables; accessible from Exports page
05

RQ3: Dissemination & Lineage Architecture

/rq3 — Cross-Domain Policy Enforcement

Configuration Inputs

ScenarioBenign, Mixed, Replay, Incest, Adversarial, Degraded
TopologyChain3, Chain5, Mesh (fully connected), Ring
Auth mixUniform (all Unclass), Mixed (U+S), Multi-tier (U+S+TS)
Seeds per scenario1–50 seeds for statistical robustness
Tracks per seed10–500 (total = seeds × tracks)
Architecture modeSAFE only, CDS (baseline guard) only, or Comparison (both)
CDS parametersGuard latency, block rate, downgrade rate, compute cost/msg
SAFE parametersZKP verify ms, Bloom check ms, recipient check ms, freshness ms

Key Metrics Computed

Fusible track %Tracks passing incest + freshness + proof checks
Incest handled %Bloom filter detections successfully quarantined to CI
Unauthorized ID leak %Attempts to infer restricted identity that reached unauthorized node
Avg hop countMean lineage depth before fusion quality degrades
Attack routingIncest/replay/sybil distribution: KALMAN vs. CI vs. REJECT
Auth visibilityField access per clearance level (position, velocity, tier, ID, sensor)
SAFE vs. CDS comparisonBandwidth, latency, leakage rate, fusion continuity side-by-side

Bloom Filter (128-bit, k=5)

  • 128-bit filter, k=5 Poseidon hash functions
  • False-positive formula: (1 - e^(-kn/m))^k
  • Saturation %, estimated FPR visualized
  • Incest triggers CI fusion mode in gatekeeper
  • Epoch rotation display (24h TTL)

Clearance-Based Field Visibility

  • Unclassified: kinematics only (position, velocity)
  • Secret: + quality tier, no identity or sensor ID
  • TS: all fields including identity and mission context
  • Restricted fields produce ENC:xxxxxxxx markers
  • Unauthorized leak count tracked per run

SAFE vs. CDS Architecture

  • SAFE: ZKP inline, per-hop, no central guard
  • CDS: centralised guard with block/downgrade rates
  • Metrics: bandwidth Mbit/s, latency ms, cores
  • SAFE: incest + replay detection without guard CPU
  • CDS: single point of failure, multi-hop breaks
06

Enhanced Simulation

/sim/enhanced — 20-Minute Maritime ISR Coalition Scenario

Scenario Configuration

Duration20 minutes (1200 seconds), 1×/2×/5× speed
ModeAnalyst (manual seek) or Demo (auto-rotate, 2× speed)
Coalition ships4 platforms: US Destroyer (TS), UK Frigate (S), Bahrain Patrol (C), French Rafale (TS)
Targets~8 contact tracks (friendly, neutral, hostile mix)
Link conditionsPer-platform dynamic degradation (Nominal → Degraded → Poor)
View modesTruth / Baseline / SAFE / Comparison (selectable)
Perspective selectorView scenario from any platform's clearance and link state
Map overlaysTruth contacts, Baseline tracks, SAFE tracks, BL failures, error ellipses, trails

Live Panel Outputs

Maritime mapContact positions, platform icons, track color-coded by detection system
ZK pipeline panelPer-track L1–L5 layer timing, success/fail bars, replays blocked counter
Gatekeeper audit trailSAFE vs. Baseline behavioral diff, event type classification
Tabbed track detailPer-contact RMS, NEES, Baseline vs. SAFE estimate comparison
Why SAFE summaryCounts: incest catches, freshness blocks, outlier downgrades, policy overrides
Narrative panelContext-aware prose explaining gatekeeper decisions
Event feedFiltered by view mode and attack type (replay, incest, spoof)
Timeline seekClick progress bar to jump to any point in the 20-min scenario

Adversarial Events in Scenario

Replay Attack
Valid-but-stale tracks injected at multiple timestamps
Data Incest
Fusion loop creates circular lineage, Bloom filter detects
Proof Spoof
Forged ZKP from compromised node, fidelity layer rejects
Link Degradation
Jammer elevates BER → wLink penalty → CI fusion
07

Research Traceability

/traceability — Requirement-to-Artifact Gap Closure Matrix

Matrix Capabilities

Total entries22 seeded requirements across RQ1, RQ2, RQ3, SIM, Dashboard, Limitations
Filter by RQRQ1, RQ2, RQ3, SIM, Dashboard, Limitation
Filter by statusAddressed, Partial, Stub, Out of Scope
Filter by evidenceUI Widget, Simulation Event, Chart, Export, Documentable Claim, Limitation
SearchFull-text across title, requirement, artifact path, tags
Expanded detailClick row → requirement, artifact, dissertation wording bullets, limitation type
Visual summariesProgress by RQ bar chart, status pie, artifact coverage heat map
Limitations sectionStub prover, trusted setup, hash-bound encryption, rate limiting, Byzantine scope

Entry Status Distribution

9
Addressed
Fully implemented with working evidence
5
Partial
Logic implemented, ZKP circuit stubbed
3
Stub
Calibrated simulation, not real crypto
5
Out of Scope
Intentional prototype scope limitation
Open Traceability Matrix
08

Export & Reporting System

/exports — Simulation Archive & Research Artefacts

Per-track CSV
One row per track event with all gatekeeper fields
RQ1, RQ2
Summary CSV
Aggregated statistics by protocol, tier, scenario
RQ1, RQ2
RMS / NEES summary
Position error and consistency metrics
RQ2
Fusion mode summary
KALMAN/CI/REJECT distribution by scenario
RQ2
Response-lag summary
Gatekeeper response latency to adversarial events
RQ2
Run summary CSV
Aggregated sim_run record with policy score stats
ALL
Events CSV
Per-event telemetry from sim_events table
ALL
JSON full run
Complete structured run + telemetry + metadata
ALL
Markdown report
Configurable research-quality report with analyst notes
ALL
HTML report
Print-ready formatted report
ALL
Comparison CSV
Side-by-side delta between two runs
ALL
RQ3 experiment JSON
Full aggregate result with lineage and dissemination tables
RQ3

File Naming Convention

safe_run_<runId>_summary.csv — run-level aggregates
safe_run_<runId>_events.csv — per-event telemetry (up to 500 rows)
safe_run_<runId>.json — complete structured dump
safe_run_<runId>_report.md — configurable markdown report
safe_run_<runId>_report.html — print-ready HTML
safe_compare_<runA>_<runB>.csv — side-by-side run comparison delta
safe_all_runs_summary_<date>.csv — bulk summary of all saved runs

All exports include generated_at timestamp, app_version, scenario name, and SIMULATION_CAVEAT header.

09

Data Persistence (Supabase)

Schema design, RLS policies, and data flow

TableRowsRLS PolicyPurpose
research_tasksPrototype mode: anon read/insert/updateRLS enabled; SELECT/INSERT/UPDATE for anon37 pre-seeded tasks across RQ1/RQ2/RQ3/SIM. Status cycling with timestamps and run counts.
proof_runsPrototype mode: anon read/insert/updateRLS enabled; SELECT/INSERT/UPDATE for anonPer-track ZKP benchmark records (RQ1 and RQ2). Indexed by experiment_label, scenario_type, mode.
sim_runsPrototype mode: anon read/insert/updateRLS enabled; SELECT/INSERT/UPDATE for anonSimulation run summaries. One row per saved execution with aggregated metrics and caveats.
sim_eventsPrototype mode: anon read/insert/updateRLS enabled; SELECT/INSERT/UPDATE for anonPer-event telemetry linked to sim_runs via run_id. Includes layer status, policy score, CI reason.
RLS note: All four tables use anon-accessible RLS policies appropriate for a single-user research prototype. A production deployment would require authenticated users with row-level ownership checks and service-role keys for server-side writes.
10

Prototype Scope & Limitations

Explicit classification of intentional constraints

Stub ZK Prover

Requires Crypto Infra

All proof generation uses calibrated timing with random hex proof strings. No real PLONK/GROTH16/STARK circuits. Requires native toolchain (circom, snarkjs, Noir).

Simulated Trusted Setup

Requires Crypto Infra

Trusted setup is a static version string "universal-srs-v2". Real deployment requires a Powers of Tau ceremony.

Hash-Bound Field Simulation

Requires Crypto Infra

Recipient binding uses deterministic hash of (value + recipientPolicyId). Production requires AES-GCM with recipient public key infrastructure.

No Server-Side Rate Limiting

Future Work

Gatekeeper rate limiting is not implemented. Production requires token-bucket throttling per coalition node.

Limited Byzantine Fault Injection

Future Work

Replay, incest, and proof spoof attacks are modelled. Deep multi-node Byzantine collusion scenarios are out of scope.

In-Memory Audit Log

Prototype Scope

UI audit log resets on page reload. Persistent evidence available via Exports → sim_events table.

Interpretation guidance: None of the above are software bugs. Each is an intentional prototype-scope decision. The prototype demonstrates architecture-level feasibility — that the five-layer SAFE design is coherent, measurable, and produces research-quality comparative evidence — without requiring a full production cryptographic stack.

11

Capability Coverage Summary

Relative feature depth across research dimensions

Feature Depth by Research Area

Navigation Index

Quick Stats

Pages: 8 major pages
API Routes: 9 backend routes
Supabase Tables: 4 tables
ZK Protocols: 4 (PLONK, GROTH16, STARK, BP)
Scenario Types: 5 adversarial scenarios
Export Formats: 11 formats
Traceability Entries: 22 requirements
Research Tasks: 37 pre-seeded
Simulation Duration: 20 min maritime ISR
Coalition Platforms: 4 ships

SAFE Prototype — SAFE-prototype-v2.0 — Report generated 2026-05-16

Secure Adaptive Fusion Environment · SYSE 701 Research Demonstrator

Cryptographic functions are simulated/calibrated. Results reflect modelled behaviour, not production cryptographic execution.