White paper
How every engine breaks into lifecycle, ingestion, normalization, computation, decision, evidence, replay, health, adapter and metering calls — and why Weather/Canopy v1 ships first.
The Foundry does not have one API call per engine. It has a reusable call grammar that can be applied to every engine and then specialized for each product.
Engine → lifecycle calls → input/ingestion calls → normalization calls → computation calls → decision calls → evidence/provenance calls → replay/export calls → health and policy calls
A single engine can therefore produce many sellable operations. A product is a composition of these operations:
Product API = Core Policy + Engines + Adapters + Evidence + Interface
The commercial opportunity is not based on claiming that every internal function is a product. It is based on identifying stable, valuable, permissioned operations that customers can call repeatedly.
Portfolio direction
The current portfolio has seven product packs: 1. Android Firewall Core.
2. Apex Mesh / Apex Beeper. 3. Vertex Filing / Local Integrity. 4. Weather / Canopy Node. 5. Environmental Anomaly Visualization. 6. GPS-denied Positioning. 7. Authorized Local Defense and Evidence. The five-engine firewall core is shared policy infrastructure, not the complete business catalog.
Commercial rule
An API call becomes sellable only when it has: • versioned input and output schema; • defined customer value; • authentication and authorization; • resource limits; • evidence and provenance behavior; • deterministic or documented model behavior; • tests and replay fixtures; • pricing or metering policy; • implementation status that is not overstated.
Every Foundry engine should be analyzed through these call classes. Class L — Lifecycle I — Ingestion N — Normalization
Purpose Create, configure, start, stop, reset Accept observations, files, messages, or device data Convert units, timestamps, identities, and formats
Typical examples engine.initialize , engine.health , engine.reset
sensor.reading.ingest , message.ingest event.normalize , timestamp.normalize
C — Computation D — Decision X — Correlation P — Policy E — Evidence R — Replay O — Output H — Health A — Adapter M — Metering
Execute the engine’s core mathematical or algorithmic work Turn computation into a recommendation, classification, or policy result Combine multiple readings, windows, or engines Enforce identity, consent, release, authorization, or safety rules Record provenance, digest, confidence, alternatives, and limitations Re-run historical events under a named model version Export reports, alerts, visualizations, or API responses Report device, model, queue, resource, and integration state Connect a device, transport, storage layer, or external boundary Count usage, compute cost, quota, and billing events
vpd.calculate , route.score dew_risk.score , route.select sensors.correlate , events.compare policy.evaluate , peer.approve evidence.create , digest.verify event.replay , route.replay packet.export , alert.emit device.health , queue.status transport.connect , node.register usage.record , quota.check
These classes are reusable across the entire catalog. Specialized calls are combinations of these classes.
These calls sit beneath multiple products and should not be duplicated inside every engine.
Identity, tenant, and consent
identity.register identity.resolve identity.rotate identity.revoke identity.verify tenant.create tenant.member.add tenant.member.remove consent.create consent.read consent.withdraw privacy.export privacy.delete
Provenance and integrity
provenance.register_source provenance.attach_commit provenance.attach_digest provenance.record_transformation provenance.verify_digest provenance.get_lineage integrity.hash_event integrity.verify_event integrity.create_manifest integrity.verify_manifest
Evidence and status
evidence.create_record evidence.append_observation evidence.attach_media evidence.attach_calibration evidence.attach_alternative evidence.attach_limitation evidence.set_confidence evidence.export_packet evidence.replay_packet status.get_readiness
status.set_readiness status.get_model_version
Metering and API operations
usage.record_call usage.get_quota usage.get_cost_estimate usage.get_usage_summary quota.check quota.reserve quota.release rate_limit.check operation.get_receipt operation.get_status
These shared calls are commercially important because customers may pay for provenance, evidence packaging, replay, and audit even when the underlying computation is simple.
The catalog distinguishes engines from adapters and products.
4.1 E-017 Wave Collapse
Role: time-window normalization, feature aggregation, correlation, and explainable confidence envelopes.
Potential API calls
wave.initialize wave.configure_window wave.ingest_sample wave.ingest_batch wave.normalize_time wave.normalize_units wave.build_baseline wave.extract_features wave.collapse_window
wave.compare_windows wave.correlate_channels wave.detect_change_point wave.score_confidence wave.explain_score wave.list_missing_evidence wave.replay wave.export_features wave.health
Primary inputs
Time-stamped scalar data, sensor streams, event windows, baseline configuration, calibration metadata, and model version.
Primary outputs
Window features, correlations, confidence, missing evidence, explainable score components, and a replayable result.
Product uses
Weather/Canopy, Environmental Anomaly Visualization, UAP Finder, Vertex evidence analysis, and authorized defensive telemetry.
Status interpretation
The engine is suitable for fixture and prototype APIs where inputs and outputs are deterministic. It does not independently identify causes.
4.2 E-018 Superposition / Barbed-Wire Supervisor
Role: observation supervision, shield lifecycle, intake state, alerts, and bounded local containment policy.
Potential API calls
shield.initialize shield.register_source shield.register_control shield.get_state shield.get_signal_state shield.get_anchor_state
shield.get_mesh_state shield.audit_controls shield.list_unbound_controls shield.open_observation_window shield.close_observation_window shield.raise_alert shield.acknowledge_alert shield.quarantine_event shield.release_event shield.set_resource_ceiling shield.activate_kill_switch shield.get_audit_log shield.replay shield.health
Primary inputs
Authorized source declarations, signal state, control state, resource ceilings, operator acknowledgements, and local event data.
Primary outputs
Shield state, alert state, control-binding audit, quarantine/release decision, resource status, and audit log.
Boundary
This is defensive supervision. Public APIs must not provide retaliation, flooding, jamming, spoofing, uncontrolled remote computation, or unauthorized access.
4.3 E-019 Android Identity and Privacy Boundary
Role: device trust, consent, identity binding, sensitive-field protection, and audit.
Potential API calls
android.register_device android.attest_device android.bind_identity android.rotate_identity android.revoke_device android.get_trust_state android.request_consent android.get_consent
android.withdraw_consent android.classify_sensitive_field android.redact_payload android.encrypt_local_record android.verify_local_record android.audit_access android.export_user_data android.delete_user_data android.health
Primary inputs
Device metadata, user consent, application scope, key references, event payloads, and policy configuration.
Primary outputs
Trust state, consent state, redacted payload, access decision, audit record, and usercontrolled export/delete result.
Boundary
Use established cryptographic primitives. Proprietary naming does not make data unbreakable. Service credentials never belong in firmware or client code.
4.4 E-020 RF Signal Fingerprinting
Role: passive RF observation, feature extraction, signal classification, and evidence labeling.
Potential API calls
rf.initialize_observer rf.register_band_profile rf.ingest_observation rf.ingest_spectrum rf.extract_features rf.build_local_baseline rf.compare_fingerprint rf.classify_signal rf.detect_change rf.correlate_with_device_state rf.attach_confidence rf.attach_alternatives rf.export_observation
rf.replay rf.health
Primary inputs
Passive observations, band profile, time, device state, calibration, and permitted local context.
Primary outputs
Feature vector, baseline deviation, classification label, confidence, alternative explanations, and evidence digest.
Boundary
Passive observation only unless a separately authorized test boundary exists. No public API for interference, jamming, spoofing, or disruption.
4.5 E-021 TriStar PE Gate
Role: intake, scrubbing, policy, timing, route/release decision, and controlled output.
Potential API calls
pe.initialize pe.register_gate pe.get_gate_state pe.ingest_payload pe.scrub_payload pe.validate_payload pe.evaluate_policy pe.check_timing_window pe.compute_tristar_index pe.score_candidate_route pe.select_route pe.handshake_gateway pe.release_payload pe.reject_payload pe.quarantine_payload pe.get_route_reason pe.replay pe.health
Primary inputs
Payload, identity, gate state, route candidates, timing window, TTL, policy, and provenance metadata.
Primary outputs
Release/reject/quarantine decision, selected route, reason codes, timing state, and evidence receipt.
Boundary
Application-layer routing and policy. It does not replace DNS, cellular standards, the public Internet, or regulated radio protocols.
4.6 Apex Mesh Message and Envelope Engine
Role: versioned encrypted message envelope, identity, expiry, replay protection, delivery state, and acknowledgement.
Potential API calls
mesh.create_identity mesh.register_peer mesh.approve_peer mesh.revoke_peer mesh.create_envelope mesh.encrypt_payload mesh.sign_envelope mesh.verify_envelope mesh.check_expiry mesh.check_replay mesh.queue_message mesh.select_transport mesh.send_message mesh.receive_message mesh.acknowledge_message mesh.get_delivery_state mesh.retry_message mesh.expire_message mesh.export_receipt mesh.health
Primary inputs
Plaintext held locally, recipient scope, key references, expiry, route ID, transport, and provenance digest.
Primary outputs
Ciphertext envelope, verification result, queue state, delivery receipt, rejection reason, and transport status.
Boundary
First release is text messaging. PTT audio is a later, separately validated capability.
4.7 Transport Adapter Layer
Role: connect the stable Apex envelope to authorized Wi-Fi, Bluetooth/BLE, cellular data, relay, Reticulum, or Meshtastic boundaries where supported.
Potential API calls
transport.list transport.register transport.configure transport.connect transport.disconnect transport.get_state transport.send transport.receive transport.retry transport.get_latency transport.get_loss transport.get_queue transport.failover transport.disable transport.health
Output classes
Connection state, send/receive result, measured latency, loss, retry count, queue state, and failover reason.
Boundary
The message model remains transport-neutral. Each transport must be tested separately and must not be advertised as ready merely because an adapter interface exists.
4.8 Apex Beeper Device Engine
Role: small ESP32/NerdMiner-style endpoint for verified text, bounded inbox, local display, acknowledgement, and offline queueing.
Potential API calls
beeper.register beeper.provision beeper.get_device_state beeper.receive_envelope beeper.verify_envelope beeper.display_message beeper.acknowledge beeper.queue_message beeper.list_inbox beeper.mark_read beeper.expire_message beeper.clear_local_record beeper.get_battery beeper.get_memory beeper.get_thermal_state beeper.enter_safe_state beeper.health
Boundary
No voice-radio replacement claim until audio, resource, transport, and safety tests are complete.
4.9 Vertex Filing / Local Integrity Engine
Role: local filing, ternary-oriented representation, buffers, canaries, checksums, anomaly scanning, recovery metadata, and export.
Potential API calls
vertex.create_record vertex.open_container vertex.write_record vertex.read_record vertex.list_records vertex.create_buffer vertex.write_canary vertex.verify_canary vertex.hash_record vertex.verify_record vertex.scan_anomalies vertex.create_recovery_map vertex.export_archive vertex.import_archive vertex.replay_verification vertex.get_capacity vertex.get_health
Primary inputs
Local records, metadata, payload digests, buffer configuration, archive path, and device state.
Primary outputs
Record ID, checksum, canary state, integrity result, anomaly list, recovery metadata, and archive.
Boundary
The prototype does not prove a physical FAT32 replacement, ten-times capacity, complete recursive storage, or self-healing hardware. Those require hardware evidence.
4.10 Weather / Canopy Sensor Engine
Role: environmental readings, VPD, dew point, condensation risk, humidity persistence, temperature swings, frost-risk indicators, and canopy history.
Potential API calls
weather.register_node weather.provision_node weather.ingest_reading
weather.ingest_manual_observation weather.attach_photo weather.normalize_units weather.calculate_dew_point weather.calculate_vpd weather.score_condensation_risk weather.score_frost_risk weather.score_humidity_persistence weather.calculate_temperature_delta weather.compare_canopy_soil weather.log_tarp_state weather.log_water_catchment weather.log_intervention weather.log_outcome weather.build_site_baseline weather.replay weather.export_evidence weather.health
Primary inputs
Temperature, RH, pressure, light/PAR, soil/sub-surface temperature, manual observation, photograph, weather context, tarp state, water event, and intervention.
Primary outputs
Reading record, calculated environmental values, threshold state, confidence, evidence packet, and intervention recommendation.
Boundary
This is decision support. It does not certify organic production, diagnose disease, guarantee yield, or provide medical advice.
4.11 Photonic / PAR / DLI Extension
Role: light availability, DLI estimation, temperature drop-rate, and tarp-orientation experiment logging.
Potential API calls
photon.ingest_reading photon.calibrate
photon.calculate_par photon.calculate_dli photon.compare_light_windows photon.log_tarp_orientation photon.log_experiment_state photon.compare_before_after photon.replay photon.health
Boundary
Claims about photosynthetic amplification, infrared trapping, or thermal benefit remain experimental until calibrated and repeatedly measured.
4.12 Environmental Anomaly Visualization Engine
Role: combine manual observations and passive environmental streams into explainable anomaly events.
Potential API calls
anomaly.create_event anomaly.ingest_manual_observation anomaly.ingest_sensor_stream anomaly.ingest_photo anomaly.normalize_event anomaly.build_baseline anomaly.extract_features anomaly.correlate_sensors anomaly.detect_deviation anomaly.score_event anomaly.generate_alternatives anomaly.list_missing_evidence anomaly.compare_events anomaly.render_visualization anomaly.replay anomaly.export_evidence anomaly.health
Primary inputs
Weather readings, motion, audio features, magnetometer, IR/thermal/depth, light, local WiFi state, photographs, and manual notes.
Primary outputs
Event state, anomaly score, confidence, correlation map, alternatives, missing evidence, visualization, and replayable evidence packet.
Boundary
An anomaly score is not a diagnosis and does not identify an extraordinary cause automatically.
4.13 E-029 Sovereign Dead Reckoning Engine
Role: step-based GPS-denied positioning, heading integration, confidence decay, and local position estimation.
Potential API calls
deadreckoning.initialize deadreckoning.calibrate_stride deadreckoning.ingest_accelerometer deadreckoning.detect_step deadreckoning.ingest_heading deadreckoning.integrate_position deadreckoning.apply_confidence_decay deadreckoning.get_position deadreckoning.get_error_radius deadreckoning.reset_anchor deadreckoning.replay deadreckoning.export_track deadreckoning.health
Boundary
Accuracy depends on calibration, sensor quality, movement, and anchor availability. No universal accuracy claim is implied.
4.14 E-030 Celestial Sensor Fusion
Role: camera/light-assisted solar position and celestial anchoring where conditions permit.
Potential API calls
celestial.initialize celestial.ingest_camera_frame celestial.detect_bright_region celestial.estimate_sky_angle celestial.ingest_light_level celestial.calculate_solar_position celestial.apply_atmospheric_correction celestial.solve_position celestial.create_anchor celestial.set_confidence celestial.replay celestial.export_anchor celestial.health
Boundary
Cloud, occlusion, camera calibration, time accuracy, and atmospheric conditions constrain the result.
4.15 E-031 Collective Mesh Inertial Navigation
Role: confidence-weighted position aggregation, hop decay, and Byzantine/outlier rejection.
Potential API calls
cmin.register_node cmin.ingest_position_report cmin.weight_report cmin.apply_hop_decay cmin.aggregate_position cmin.calculate_error_radius cmin.detect_outlier cmin.reject_suspicious_node cmin.restore_node_trust cmin.get_collective_position cmin.replay cmin.export_consensus cmin.health
Boundary
A mesh consensus result is only as good as its reports, timing, calibration, and trust assumptions.
4.16 Transponder / Device Bridge
Role: connect authorized serial, NMEA, AIS, aviation, maritime, or other device streams to normalized anchors.
Potential API calls
bridge.discover_devices bridge.get_device_status bridge.connect bridge.disconnect bridge.read_stream bridge.write_stream bridge.parse_nmea bridge.parse_ais bridge.normalize_anchor bridge.push_anchor bridge.get_anchor_history bridge.get_audit_log bridge.check_fcc_boundary bridge.health
Boundary
Only operate on authorized devices and frequencies. Regulatory and hardware compliance remain deployment responsibilities.
4.17 Radio Gate / Authorized Local Defense
Role: local observation, decoy/honeypot state, bounded containment, PCAP/evidence receipt, and defensive audit.
Potential API calls
radio.observe radio.classify radio.register_local_decoy radio.get_decoy_state radio.capture_evidence radio.store_pcap_metadata radio.rate_limit_local radio.quarantine_local_peer radio.apply_kill_switch radio.get_resource_ceiling radio.get_audit_log radio.replay radio.health
Boundary
No retaliation, jamming, flooding, exploitation, public-network disruption, or uncontrolled resource exhaustion.
4.18 Observed-versus-Known Verification Engine
Role: continuously compare actual observations against a declared known input, expected state, prior baseline, or model projection, then measure residual error, drift, confidence, and repeatability. This is a distinct engine class, not a note field. It turns the Foundry's longitudinal records— including the five-year False Daisy Farms experience—into a reusable verification service.
Known input / expected state / prior model ↓ Actual observation or sensor event ↓ Time and unit normalization ↓ Residual and deviation calculation ↓ Drift, confidence, and repeatability analysis ↓ Verification result + provenance record
Potential API calls
verify.register_known_input verify.register_expected_state verify.register_model_projection verify.ingest_observation verify.normalize_pair verify.calculate_residual verify.calculate_percent_error verify.detect_drift verify.detect_regime_change verify.compare_time_windows verify.compare_sites verify.score_repeatability verify.score_confidence verify.list_disconfirming_evidence verify.accept_or_reject_hypothesis verify.create_verification_record verify.replay verify.export_report verify.health
Example uses Known input predicted dew-risk window
Actual observation time-stamped canopy photo and RH reading
expected thermal differential
canopy/soil node readings
known radio fingerprint at a coordinate
current radio observation
expected route/gateway state
observed delivery receipt and RTT
predicted sensor anomaly
multi-sensor event
expected intervention outcome later field observation
Five-year longitudinal mode
Verification result prediction residual and confidence Hügelkultur thermal-runway estimate anchor match, age, and location confidence route-model residual correlation, alternatives, and falsification state outcome and repeatability record
The engine should support historical records without treating age alone as proof. Each comparison carries: • observation time and source; • known-input/model version; • site or device scope; • calibration and unit state; • residual/error; • missing or conflicting evidence; • intervention between prediction and observation; • confidence and repeatability; • provenance digest. The output can state that a projection was supported, contradicted, or unresolved for a defined site and time window. It must not silently convert one successful anecdote into a universal law.
Product combinations
This engine becomes a shared verification layer for Weather/Canopy, Environmental Anomaly Visualization, radio-anchor navigation, ADP routing, Vertex evidence, and authorized lab testing. It is especially valuable because it converts “we observed this five years ago” into a queryable, versioned, testable comparison against what is observed now.
4.19 Continuous radio-environment presence verification
A past GPS-known radio coordinate is only a candidate anchor. Before using it for presenttime location, the device must run a repeatable current-presence routine—a radioenvironment verification sweep—to determine whether the expected signal is actually present now.
Historical anchor candidate ↓ Current radio scan / passive observation ↓ Fingerprint comparison and time alignment ↓ Superposition / determinant-engine fusion ↓ Independent sensor and route-consistency checks
↓ Current-presence state ↓ Use, downgrade, quarantine, or expire anchor
Current-presence states
confirmed_current probable_current weak_match not_observed conflicting_observation stale_anchor spoof_or_replay_suspected
Potential API calls
radio_sweep.start radio_sweep.collect_window radio_sweep.collect_repeated_windows radio_sweep.normalize_environment radio_sweep.compare_to_anchor radio_sweep.compare_to_local_history radio_sweep.fuse_with_superposition radio_sweep.fuse_with_determinant_route_state radio_sweep.cross_check_motion radio_sweep.cross_check_inertial_position radio_sweep.cross_check_weather_or_device_state radio_sweep.score_current_presence radio_sweep.set_presence_state radio_sweep.downgrade_anchor radio_sweep.quarantine_anchor radio_sweep.expire_anchor radio_sweep.create_verification_record radio_sweep.export_evidence radio_sweep.health
The routine should be periodic, event-triggered, and on-demand. Repeated sweeps should capture signal identity/features, observed strength or quality, timing, device calibration, local interference context, motion state, and any independent anchor agreement. The
determinant/TriStar engine can help combine the observations, but it must not manufacture current presence from a historical coordinate alone.
Present-location acceptance rule
An anchor may be used for a live location correction only when the current sweep meets the configured evidence threshold. Otherwise the engine must return a degraded estimate, preserve the historical anchor as inactive context, and continue inertial drift with an explicitly widening uncertainty bound.
8C. TriStar radio-source confidence and cooperative location model
The TriStar thought-process/verification layer should classify radio sources by evidence quality, not treat every observed SSID or signal as equally reliable. The proposed percentages are initial policy scores and priors for testing, not calibrated probabilities and not guarantees of physical truth.
Initial source classes Source class
Initial policy score
Known cellular tower from an open, licensed tower-location source plus current in-field match
0.95 prior; may reach the highconfidence band after current verification
Home or local Wi-Fi SSID from a historical known location
0.50 prior
Current authenticated device high-confidence candidate; observation with synchronized policy may mark the timing and repeated feature observation event as verified match Multiple consenting team devices mutually observed within a bounded local area
confidence increase through independent corroboration
Reason Fixed infrastructure is more stable, but spoofing, repeater behavior, stale databases, and propagation effects remain possible The network may be offline, moved, renamed, hidden, duplicated, or spoofed; presence is not guaranteed Current observation is stronger than historical presence, but measurement and synchronization error still exist Cooperative agreement reduces single-sensor error but does not create mathematical certainty
TriStar evidence progression
Historical known location ↓ Current signal observed ↓ Fingerprint and timing match ↓ Independent sensor agreement ↓ Consenting peer/team corroboration ↓ Current location estimate with confidence and error radius
The engine should retain separate values for: • priorScore : confidence before the current sweep; • observationScore : quality of the current radio observation; • corroborationScore : independent device or sensor agreement; • spoofRisk : replay, clone, repeater, or mismatch risk; • timingQuality : clock synchronization and measurement-window quality; • locationConfidence : final bounded estimate; • errorRadius : physical uncertainty in meters; • verificationState : candidate, current, corroborated, degraded, or rejected.
Millisecond observation windows
Millisecond-scale observation windows can support low-latency time-of-arrival, timedifference, signal-feature, or movement estimates when the hardware clocks, sampling rate, reference points, and propagation model support them. They do not automatically prove instantaneous or exact trilateration. The API must report timing precision, clock uncertainty, multipath risk, geometry, and error radius. Use current_observation_verified for a current event that passed the configured checks, not physically_certain . A policy may expose a 1.00 event-verification score for a fully verified observation record while still returning a nonzero physical location error radius.
Cooperative team mode
With explicit consent, each team device can publish a signed, time-bounded radio observation. The engine compares the observations, checks whether they are independently sourced, and produces a group-consensus result. Each participant should see their own visibility and sharing state. Team consensus is an additional evidence layer, not permission to track people without authorization.
Potential API calls
tristar.register_source_class tristar.set_prior_score tristar.ingest_current_observation tristar.align_observation_window tristar.match_fingerprint tristar.score_spoof_risk tristar.score_timing_quality tristar.ingest_peer_observation tristar.check_peer_consent tristar.calculate_corroboration tristar.calculate_location_confidence tristar.calculate_error_radius tristar.set_verification_state tristar.create_location_receipt tristar.replay_verification tristar.export_consensus
The engine calls become products by composing them behind a customer-facing contract.
Pack A — Android Firewall Core Customer-facing calls
firewall.register_device firewall.get_trust_state firewall.ingest_observation firewall.classify_signal firewall.evaluate_policy firewall.scrub_payload firewall.quarantine_event
firewall.release_event firewall.raise_safety_alert firewall.get_audit_log firewall.export_evidence firewall.health
Composition
E-017 + E-018 + E-019 + E-020 + E-021
Commercial customers
Authorized labs, device owners, security teams, hardware demonstrators, and enterprise telemetry operators.
Pack B — Apex Mesh / Apex Beeper Customer-facing calls
mesh.register_peer mesh.create_message mesh.send_message mesh.receive_message mesh.get_delivery_state mesh.approve_peer mesh.revoke_peer mesh.get_transport_state beeper.get_inbox beeper.acknowledge mesh.export_receipt
Composition
E-019 + E-021 + Message Engine + Transport Adapters + Vertex optional
Pack C — Vertex Filing / Local Integrity Customer-facing calls
filing.create_record filing.append_event filing.verify_record filing.verify_manifest filing.scan_anomalies filing.create_recovery_map filing.export_archive filing.replay_verification filing.get_integrity_status
Composition
Vertex + E-019 + E-021 optional + device/storage adapters
Pack D — Weather / Canopy Node Customer-facing calls
weather.register_node weather.submit_manual_observation weather.ingest_sensor_reading weather.calculate_vpd weather.calculate_dew_point weather.score_condensation_risk weather.score_frost_risk weather.compare_canopy_soil weather.log_tarp_state weather.log_water_catchment weather.log_intervention weather.log_outcome weather.export_evidence
Composition
E-017 + Vertex + sensor adapters + Android PWA
E-018 and E-021 may be added for supervised alerting and controlled release.
Pack E — Environmental Anomaly Visualization Customer-facing calls
anomaly.submit_observation anomaly.submit_sensor_stream anomaly.build_baseline anomaly.correlate anomaly.score anomaly.explain anomaly.compare anomaly.render anomaly.export_evidence anomaly.replay
Composition
E-017 + E-018 + E-020 + Weather Node + Vertex + sensor adapters
Pack F — GPS-denied Positioning Customer-facing calls
navigation.start_track navigation.ingest_motion navigation.ingest_heading navigation.add_celestial_anchor navigation.add_mesh_report
navigation.aggregate_position navigation.get_confidence navigation.get_error_radius navigation.export_track navigation.replay
Composition HTML
E-029 + E-030 + E-031 + device bridge + optional TriStar/PE policy
Pack G — Authorized Local Defense and Evidence Customer-facing calls
defense.register_scope defense.observe defense.classify defense.capture_evidence defense.rate_limit_local defense.quarantine_local defense.activate_kill_switch defense.get_resource_state defense.export_audit
Composition
E-018 + E-019 + E-020 + E-021 + Radio Gate + Vertex
The following combinations are the highest-value pairings. Each pair should have a defined contract rather than an informal code import.
Hardware execution topology: local routing/text side plus accesspoint side The intended physical assembly is a split local data path:
Routing + text assembly side ⇄ local inter-core/inter-chip boundary Access-point / transport side ⇄ daisy-chained neighboring node
In the target implementation, one processing side runs the Apex routing and text-envelope assembly that already exists in the preserved source, while the other side runs the accesspoint/transport boundary. Multiple assemblies can be daisy-chained so that the message contract remains stable while the physical path expands. This should be exposed as separate internal and customer-facing calls:
node.route_text node.assemble_envelope node.forward_to_ap node.receive_from_ap node.forward_daisy_chain node.get_link_state node.get_hop_count node.get_queue_state node.get_resource_state node.health
The split reduces coupling: routing and message construction can be tested independently from AP/transport behavior. The daisy-chain must preserve message ID, expiry, replay protection, route ID, hop count, acknowledgement state, and provenance across every hop.
Bidirectional pager and 5G adaptation
The Apex Beeper/pager is not a receive-only display. It is a bidirectional endpoint:
Pager receives text → verifies envelope → displays and acknowledges → can compose/send text
→ routing protocol selects the authorized return path → local AP / daisy chain / 5G data adapter
The same message contract must work in both directions. The pager can hand an outgoing message from the local daisy-chain back to an authorized 5G wireless data network through the routing/transport adapter. Conversely, an incoming 5G-routed message can be delivered back through the AP and daisy-chain to the pager. The routing protocol is therefore the adaptation layer between the small text endpoint and the wider 5G data boundary; it is not a claim that the pager itself contains a cellular modem or that 5G coverage is universal. Additional endpoint calls are:
pager.receive_text pager.verify_incoming pager.display_text pager.acknowledge_text pager.compose_text pager.send_text pager.route_to_5g pager.receive_from_5g pager.get_network_path pager.get_delivery_receipt
Required validation includes bidirectional send/receive, offline queueing, 5G adapter availability, route failover, expiry, replay rejection, acknowledgement continuity, and preservation of provenance across pager → AP → daisy chain → 5G and the reverse path. The exact assignment—two cores on one dual-core chip versus two chips or boards—must be recorded per hardware profile. The source may already contain the routing and text assembly, but the physical execution topology is not marked hardware-validated until a named board, firmware build, interconnect, queue behavior, thermal profile, and repeatable multi-hop run are documented. Combination E-017 + E-018 E-017 + E-019 E-017 + E-020
Shared operation correlate observation windows under shield supervision correlate privacy-bound device events correlate time windows with passive RF features
Product value anomaly and lab evidence Android privacy telemetry environmental/RF anomaly view
E-017 + E-021 E-018 + E-019 E-018 + E-020 E-018 + E-021 E-019 + E-021 E-020 + E-021 E-021 + Vertex E-017 + Vertex E-018 + Vertex Weather + E-017 Weather + Vertex Weather + Photonic Weather + Anomaly Weather + E-021 Anomaly + E-020 Anomaly + Vertex E-029 + E-030 E-029 + E-031 E-030 + E-031 E-029 + Device Bridge
collapse timing windows into gated route decisions supervise trusted device lifecycle supervise passive RF observation supervise controlled intake/release
ADP route scoring Android firewall authorized RF evidence policy gate
envelope and route identity-bound payload release secure policy classify signal before policy RF-aware gated routing release gated filing and integrity receipt protected local evidence correlated event filing and evidence vault replay supervised audit persistence shield evidence environmental window analysis VPD/dew/frost trends time-stamped local canopy history environmental archive light/temperature/tarp photonic telemetry experiment environmental baseline and UAP/environmental visualizer event score controlled alert/release safe field notification environmental/RF correlation lab observation evidence packet and replay UAP Vault dead reckoning with celestial GPS-denied navigation anchors individual track plus mesh distributed positioning consensus celestial anchor shared across collective positioning mesh external anchor correction field navigation
E-031 + TriStar Mesh + E-019 Mesh + E-021 Mesh + Vertex
sensor/camera anchor ingestion mesh position route indexing identity-bound messages gated message release local message filing
Mesh + Transport
carrier-agnostic delivery
Radio Gate + E-018 Radio Gate + E-020 Radio Gate + Vertex Radio Gate + E-021
local defensive supervision passive RF classification PCAP/evidence filing policy-gated local action
E-030 + Device Bridge
navigation adapter positioning API Apex Mesh policy-aware messaging offline Beeper multi-transport communications authorized lab defense signal evidence audit packet bounded containment
Higher-order combinations are product assemblies, not necessarily new engines.
Weather + Wave + Vertex
weather.ingest_reading → wave.build_baseline → wave.collapse_window → vertex.create_record → weather.export_evidence
Use: canopy history, dew/frost trend, manual versus sensor comparison.
Weather + Wave + Photonic + Vertex
weather.ingest_reading → photon.calculate_dli → wave.correlate_channels
→ vertex.attach_calibration → evidence.export_packet
Use: tarp-orientation experiments and light/temperature comparisons.
Weather + Anomaly + RF + Vertex
weather.ingest_reading → rf.ingest_observation → anomaly.correlate_sensors → anomaly.generate_alternatives → vertex.export_archive
Use: environmental anomaly visualization with passive RF context.
Anomaly + Shield + Privacy + Vertex
android.request_consent → shield.open_observation_window → anomaly.ingest_sensor_stream → anomaly.score_event → vertex.hash_record → shield.close_observation_window
Use: authorized lab or shielded-room evidence collection.
Mesh + Privacy + PE Gate + Transport + Vertex
identity.verify → mesh.create_envelope → pe.evaluate_policy → transport.select → mesh.send_message → vertex.create_record
Use: Apex Mesh text messaging with identity, policy, transport, and local evidence.
Dead Reckoning + Celestial + CMIN + Device Bridge
deadreckoning.ingest_accelerometer → celestial.create_anchor → cmin.ingest_position_report → cmin.aggregate_position → bridge.push_anchor
Use: GPS-denied field navigation with multiple confidence sources.
Defense + RF + PE Gate + Vertex
radio.observe → rf.extract_features → pe.evaluate_policy → shield.quarantine_event → vertex.export_archive
Use: authorized local defensive telemetry and evidence capture.
If the seven product packs are treated as selectable modules, the theoretical non-empty combination space is:
2^7 - 1 = 127 possible pack subsets
That does not mean 127 products should be built. Many combinations are redundant, unsafe, commercially unclear, or technically incompatible.
Commercially coherent combinations Assembly Weather only Weather + Vertex Weather + Anomaly
Primary customer value low-cost field telemetry environmental history and evidence visual anomaly product
Recommendation first build first expansion second product surface
Weather + Photonic Mesh + Beeper Mesh + Vertex Firewall + Mesh Firewall + Anomaly Anomaly + UAP Vault GPS Navigation + Device Bridge GPS Navigation + Mesh Defense + Vertex Defense + Firewall Weather + Mesh + Vertex Weather + Anomaly + Vertex + Firewall
light/tarp experiments text endpoint offline verified inbox policy-aware communications authorized lab observation consumer/lab evidence archive field positioning distributed field coordination evidence-backed local defense Android defensive telemetry field sensor reporting and transport
experimental extension separate hardware track strong bundle later enterprise bundle controlled deployment product showcase separate technical pack later integration authorized-only core enterprise bundle
full environmental/lab stack
later, evidence-heavy
future community deployment
Combinations to prohibit or defer
• Any public API that combines defensive observation with retaliation or disruption. • Any combination that assumes unsupported live-world routing or zero-time delivery. • Any product that exposes raw personal medical context with environmental data by
default. • Any actuator combination without manual override, safe state, resource ceiling, and electrical/thermal testing. • Any multi-node or multi-engine product that lacks independent replay fixtures for each component.
8A. TriStar aerial and field-operations adapter
The expanded TriStar routing concept can support authorized aerial and field-operation message classes for agricultural monitoring, wildfire observation and response
coordination, fireworks-event mapping, and special mapping. The safe abstraction is an application-layer mission and telemetry envelope, not an unrestricted remote-actuation API.
Address-space correction
The proposed “150 quadrillion” figure should be treated as a possible logical namespace or route-space target, not as a claim that 150 quadrillion physical endpoints exist or are reachable. The current ADP/TriStar paper establishes a defined combinatorial model, including the documented 10! configuration-space interpretation; a larger namespace would require a new formal specification and regenerated implementation proof. An 8-bit header contains 256 possible values. It is suitable for compact control fields such as:
version / message class / priority / flags / hop behavior / acknowledgement mode
It is not sufficient by itself to identify a huge endpoint space. The protocol should separate:
8-bit compact header + variable-length route ID + endpoint or mission ID + hop count / expiry + authenticated payload + provenance digest
Potential aerial-adapter calls
aerial.register_platform aerial.register_mission aerial.issue_telemetry_header aerial.route_to_endpoint aerial.forward_daisy_chain aerial.ingest_position aerial.ingest_sensor_payload aerial.map_observation aerial.set_geofence aerial.check_airspace_policy aerial.check_weather_window
aerial.require_operator_ack aerial.log_command_receipt aerial.abort_mission aerial.export_evidence aerial.health
Domain-specific uses Domain Agriculture Firefighting Fireworks events Special mapping
Safe first use crop, soil, thermal, moisture, and canopy telemetry authorized mapping, smoke/heat observation, crew situational awareness perimeter mapping, crowd/airspace observation, event telemetry; no automatic pyrotechnic firing terrain, infrastructure, environmental, and disaster-area mapping
Mandatory boundaries
• Platform ownership and operator authorization must be verified. • Geofences, airspace rules, weather limits, battery state, and return/abort behavior must
be checked before dispatch. • Telemetry and mission metadata are distinct from physical actuation. • Any actuator command requires explicit policy, operator acknowledgement where appropriate, a kill/abort path, and an audit receipt. • Firefighting and fireworks deployments require domain-specific safety review; the general routing API must not silently grant hazardous control authority. • Every hop preserves route ID, endpoint ID, message class, expiry, authentication, acknowledgement state, and provenance.
8B. Radio-fingerprint anchors for GPS-denied location
The Superposition, E-020 RF, E-029 dead-reckoning, and E-031 collective-inertial applications can benefit from a known-location radio fingerprint layer. A WiGLE-like source, a user-generated drive survey, or another authorized database can provide
observations where a radio signature was recorded at a GPS-known location. Those observations become candidate anchors—not automatic truth—for inertial location estimation.
Known-location radio observation ↓ Fingerprint normalization and confidence ↓ Local/on-device signed cache ↓ Superposition anchor selection ↓ E-029 inertial dead reckoning correction ↓ E-031 multi-node confidence aggregation ↓ Offline map layer / field display
Potential API calls
radio_anchor.register_source radio_anchor.ingest_known_location radio_anchor.normalize_observation radio_anchor.hash_fingerprint radio_anchor.score_anchor_confidence radio_anchor.deduplicate_observation radio_anchor.query_nearby_fingerprints radio_anchor.select_anchor radio_anchor.cache_on_device radio_anchor.verify_cache radio_anchor.expire_cache radio_anchor.revoke_source superposition.add_radio_anchor superposition.fuse_radio_anchor superposition.compare_anchor_sources inertial.correct_with_anchor inertial.get_position_confidence inertial.export_track map.create_offline_layer map.export_geojson map.export_mbtiles_metadata
map.export_atak_overlay map.verify_map_digest
Data and evidence requirements
Each anchor should carry, at minimum: • source and collection method; • GPS-known coordinate or bounded area; • observation timestamp and age; • radio feature/fingerprint digest; • coordinate uncertainty; • device/calibration metadata where available; • source reputation or confidence; • consent/licensing status; • expiry and revocation state. The on-device flash cache should be signed, bounded, versioned, and queryable offline. A cached radio fingerprint is a historical observation, not proof that the transmitter remains at that location. The fusion engine must reduce confidence for stale, sparse, conflicting, spoof-suspect, or poorly calibrated anchors.
Map output boundary
The system can generate device-local map layers and export formats suitable for an authorized ATAK-compatible workflow, subject to the target format, licensing, and integration tests. “ATAK-compatible” is an adapter requirement, not a claim that the current source already produces a validated ATAK plugin or complete map package.
External-source boundary
WiGLE is not currently enabled as a connector in this session. Copilot may define a providerneutral adapter for WiGLE or another authorized source, but must not hard-code credentials, scrape unapproved data, or treat third-party observations as authoritative without provenance, licensing, rate limits, and freshness handling. A local drive-survey importer can provide the same schema without external dependency.
Source-only
Located in preserved repositories but no reproducible call contract.
Prototype
A call or product path executes locally, but inputs, outputs, failure states, or resource limits remain incomplete.
Fixture
A deterministic replay or simulation exists and passes known assertions.
Adapter-only
The device, transport, or storage boundary exists, but the underlying capability is incomplete.
Hardware-validated
The exact target device has a repeatable flash/run record, measurements, and limitations.
API-ready
The API contract, tests, provenance, security/privacy, metering, failure behavior, and release policy are complete.
Commercial
The API or product has approved pricing, licensing, support, operational monitoring, customer documentation, and an authorized release decision. A call may be fixture while the containing product remains prototype .
Pricing should follow value and resource cost rather than raw function count.
Low-cost calls
• Manual observation submission. • Unit normalization. • Basic VPD/dew-point calculation. • Device health. • Evidence metadata.
Metered analytical calls
• Baseline construction. • Multi-sensor correlation. • Anomaly scoring. • Event comparison. • Route scoring. • Position aggregation. • Replay under a new model version.
Premium calls
• Evidence packet generation. • Long-window historical analysis. • Multi-node aggregation. • Enterprise policy evaluation. • Hardware fleet health. • Private model/version deployment. • High-retention provenance and audit.
Bundle products
• Weather Node starter subscription. • Weather Node sensor fleet tier. • Apex Mesh personal tier. • Apex Mesh operator tier. • UAP Finder consumer/lab tier. • Authorized lab evidence tier. • GPS-denied field-navigation tier.
No prices should be finalized until call cost, storage, support, and validation status are measured.
The first commercial catalog should remain small enough to implement and test.
Weather / Canopy v1
weather.submit_manual_observation weather.attach_photo weather.ingest_sensor_reading weather.calculate_vpd weather.calculate_dew_point weather.score_condensation_risk weather.build_site_baseline weather.log_intervention weather.log_outcome weather.export_evidence
Environmental Anomaly v1
anomaly.submit_observation anomaly.ingest_sensor_stream anomaly.build_baseline anomaly.correlate anomaly.score anomaly.explain anomaly.compare anomaly.export_evidence anomaly.replay
Shared foundation v1
identity.verify consent.check provenance.attach_digest evidence.create_record usage.record_call operation.get_receipt
These calls create a complete first product without waiting for every engine and adapter in the repository to become commercial.
Copilot should not try to expose every internal function as a public endpoint. Copilot should: 1. Build an engine registry. 2. Map internal functions to the call taxonomy. 3. Identify stable input/output boundaries. 4. Mark each call as source-only, prototype, fixture, adapter-only, hardware-validated, APIready, or commercial. 5. Select one product pack per branch or declared implementation slice. 6. Build Weather/Canopy v1 first. 7. Add manual mode before requiring hardware. 8. Preserve photo, timestamp, consent, digest, intervention, and outcome fields. 9. Add replay fixtures before multi-engine correlation. 10.Keep all original repositories and branches unchanged. 11.Push only the designated branch after approval of the exact change packet.
The Foundry’s true commercial unit is not “an engine.” It is:
A named operation + a stable contract + a measurable input/output + a permission boundary + a provenance record + a usage meter + a customer outcome
The broad engine portfolio creates a large potential call surface, but the correct path is staged:
Weather manual mode → Weather single-node mode
→ Weather multi-node mode → Environmental anomaly visualization → Evidence and replay APIs → Mesh/Beeper product → GPS/navigation product → Enterprise authorized-defense bundles
The immediate value is not a claim of instant wealth. The immediate value is that the Foundry can transform one proven or promising computation into multiple well-defined, testable, permissioned services without rewriting the underlying engine each time.
Published summary of an attorney-review draft or engineering record — not a filing, not a patentability opinion, not a safety certification. Engine parameters, signing keys and customer records never appear in any published paper.