Physical Reality Sentry — Pre-NDA Whitepaper

Continuous Multi-Dimensional Attestation for Enterprise Software Infrastructure

Version 1.4 · September 2026
Prior edition: Version 1.3 is unchanged and remains the prior freeze.
Patents: 8 U.S. provisionals filed · 11 additional draft-ready
Status: Pre-NDA public edition · cleared for public distribution

Author: Arthur Gardner (inventor); entity: NanŌmics™ PBC, a Delaware public benefit corporation.
Contact: info@nanomics.io

Companion publications (Resources): DTS edition 4.4 · IACR ePrint draft, version 1.8 — force7_v2/v2_Latest/IACR_DTS_SECURITY_MODEL_2026_v1.8.md (not submitted) · 11 September 2026 attack-surface board
The DTS file posted at that Resources address is edition 4.4, and the copy of this whitepaper posted there is version 1.4.
This edition focuses on the Physical Reality Sentry product architecture. Proprietary scoring internals are not disclosed.

Public Benefit Statement (verbatim from NanŌmics PBC certificate of incorporation):

ABSTRACT

The Physical Reality Sentry Platform™ is the commercial embodiment of Gardner Distributed Thermodynamic Security (DTS). It sits outside the compute plane of the systems it observes. It does not replace SIEM, EDR, identity providers, or existing SOC tooling. It is additive. It reads from enrolled systems and inbound alert streams, and it writes back signed attestation state, tamper signals, and triage enrichment so operators act on independent evidence.

The accept rule has two stages. An epoch is certified only when it passes both.

Stage 1 is the posterior. The attestation server runs a Bayesian stack over the thermodynamic fingerprint of the room the witness sits in, and that reading must clear a quality gate and a matching gate. Quality means the sample is good enough to judge. Matching means it looks like the room it was enrolled as. Stage 1 is about this room, on this node, in this epoch. It is not the stacking bound across many rooms described below and in §8.2.

Stage 2 is the five-class conjunction: physical AND cryptographic AND logistical AND statistical AND temporal, all in the same signed epoch. Physical means the environment signal is genuine. Cryptographic means the epoch is signed by the enrolled key and the signature verifies. Logistical means the witness is in the place it was enrolled to. Statistical means the reading matches the enrolled baseline inside the policy gate. Temporal means the epoch is fresh and unused. All five must hold in the same signed epoch. A single class cannot carry an accept.

Both stages must pass. The accept rule is the conjunction of the two stages, and it is the rule the verifier runs. It defines when an epoch is certified. It is not a result derived from assumptions.

Hardware, software, autonomous AI agents, and human operators are enrolled into the graph. They are enroll slots, not additional accept doors. The three pulses — the Hardware Reality Pulse™, the Software Reality Pulse™, and the AI Reality Pulse™ — supply evidence that feeds the five classes. They are not three separate wins. The server sets the statistical and physical class bits from submitted evidence. The client does not decide whether an epoch is genuine.

What has been measured, and what has not. On 26 May 2026 the production entropy authenticity posterior rejected five of five scripted forgeries, including a statistical mimicry frame built to look plausible, and accepted the genuine control. That result is labeled Demonstrated. It covers Stage 1 of the accept rule, on one node. It does not cover Stage 2. On 11 September 2026 a lab board of 47 attack-surface cases was run against Stage 2, the five-class conjunction, on the enrolled-write path: 45 held, and 2 honest controls were accepted as expected. That board is labeled an experiment, not a Demonstrated result.

The stacking bound is a separate claim about many rooms. Each enrolled room carries its own posterior. Joint false-accept across n independently certified rooms is bounded by the product of the per-room rates — written αⁿ, where α is the single-room rate and n is the number of rooms — and that bound is Theorem A, stated under conditions printed in §8.2. At a thousand independently certified rooms the bound is about 9.6 × 10⁻⁸⁴, an Internal estimate: arithmetic under the independence condition, not a measured thousand-node deployment. The single-node input to that arithmetic is a stacking input, not a pass rate and not a product claim (§8.3). Those printed conditions belong to the many-room stacking bound. They are not what certifies one epoch. One epoch is certified by the two-stage accept rule, and Stage 1 of that rule is this room’s own posterior, not the product across n rooms.

Theorem B is a second conditional-if statement. It is the modeled full sum under printed ifs. It is listed in the companion IACR draft version 1.8. It does not enlarge Theorem A. It does not certify one epoch.

The Gardner Conjecture remains open. It is not proved here. Neither stage of the accept rule proves it. Theorem A and Theorem B do not close it.

Certified epochs are fused into a Merkle tree whose root anchors on Solana (currently devnet; production Solana with the first customer deployment). Only certified rows enter the tree. The Solana write anchors the record. It is not part of the accept rule. Reality Pulse Meter™ counts certified epochs on the enrolled stack. PoPTriage™ time-joins inbound alerts to certified epochs for triage enrichment. Proof of Presence™ (PoP), the underlying method, is grounded in 8 U.S. provisionals filed, with 11 additional applications draft-ready.

This paper follows the deployed path in order: enrollment, sensors, thin client, the two-stage accept rule (Stage 1 posterior, then Stage 2 five-class AND), reject, stacking, Merkle fuse, and the chained ledger returning certified state to the customer SOC. Each empirical result carries its own claim label. Trade-secret scoring internals are omitted.

1. INTRODUCTION AND THE ACCEPT RULE

Autonomous systems now act faster than the people responsible for them can review. The security tools meant to watch those systems run inside the same compute plane the systems run in, which means the record of what happened is produced by the thing being questioned. That is the problem this platform was built to address, and it was approached from first principles: physical signals, measured outside the compute plane, committed to a record the operator does not have to take on faith.

1.1 The Circular Trust Problem

Every security product deployed in an enterprise requires trust in the vendor. A team that deploys endpoint detection software must trust that the software has not been compromised. When a vendor says its running software matches the certified version, the customer accepts that claim without independent verification. This is the circular trust problem: the tool meant to establish trust must itself be trusted, without a check outside the same boundary.

The cost is real. Security vendors are attractive targets, because compromising the tool compromises every enterprise it protects. The 2020 SolarWinds attack showed this. Attackers compromised the software supply chain of a trusted vendor and reached thousands of enterprise environments at once. The security tool became the attack vector.

No prior system fixed this, because no prior system let the tool prove its own integrity to a record outside the tool’s developer, again and again, without trust in that developer.

1.2 The Runtime Integrity Gap

Software integrity checks usually run at build or install time, not continuously at runtime. Code signing verifies that software was signed by the developer at build and that the signature is valid at install. It says nothing about whether the binary running at 14:32:00 UTC today is the binary verified six months ago. Runtime protection systems watch for attacks inside a running application, but they do not verify the application’s own binary at the runtime level.

That leaves a gap. Software can be changed after install and before the next scan, and it runs unverified in between. For a platform whose job is to report on compromise, that gap is exactly the window an attacker wants.

1.3 The AI Agent Verification Problem

Autonomous AI agents now run consequential operations in finance, healthcare, government, and enterprise systems. A new question follows: how does an enterprise know an agent is genuinely authorized, running the certified model, on genuine hardware, and acting within scope? Identity systems check digital credentials, not physical presence. An attacker who steals an agent’s credentials can run a rogue agent that looks legitimate at the digital identity layer.

1.4 The Accept Rule — Two Stages

The Physical Reality Sentry Platform grounds identity in physical signals committed to a record outside the compute plane. Its method is Proof of Presence (PoP).

The core of the design is one rule with two stages. An epoch is certified only when both stages pass on that same signed epoch.

Stage 1 — the posterior on this room. The attestation server runs its Bayesian stack over the environment reading submitted with the epoch and returns a posterior on that reading. The posterior must clear two gates. The quality gate asks whether the sample is good enough to judge. The matching gate asks whether it looks like the room the witness was enrolled as. Stage 1 is about this room, on this node, in this epoch.

Stage 2 — the five-class conjunction. All five of the following must hold in that same signed epoch:

The two stages ask different questions. Stage 1 asks how good this room’s reading is. Stage 2 asks whether every class holds at once. Certify only if both pass. One miss on either stage and the record is not certified. There is no partial credit.

What kind of statement this is. The accept rule is a definition. It says when an epoch is certified, and the verifier runs it exactly as written. It carries no printed conditions, and it is not offered as a proof of anything. A mechanized check confirms that the Stage 2 conjunction is evaluated as stated; that check confirms the definition and nothing beyond it. Separate statements with their own conditions — Theorem A (the posterior stacking bound in §8.2), Theorem B (the modeled sum under printed ifs in §8.2b), and the Gardner Conjecture in §16 — are kept apart from this rule throughout the paper.

Hardware, software, AI agents, and human operators are enrolled into the graph; enrollment adds slots to the record, not new accept doors. The three pulses gather evidence that feeds the two stages. A hash mismatch in the Software Reality Pulse raises a notice; it is not a sixth class and it does not by itself certify or de-certify an epoch (§2.5). AI enrollment is not a pre-condition for closing an epoch (§2.6).

The statistical and physical class bits are set by the verifier from submitted evidence. The client samples, hashes, and signs. The client does not decide whether an epoch is genuine.

1.5 Two Views of the Same Path

The rest of this paper walks the deployed path in order. Two figures show that path first: the process as a flat sequence, and the same cycle as the round trip between the site and the attestation server. They describe one path, not two designs.

Figure A. The deployed path as a flat sequence, numbered to match sections 2 through 10. Enrollment comes first: nothing writes an epoch before it is enrolled. The accept rule runs across steps 3 and 4: Stage 1 is this room’s posterior, Stage 2 is the five-class conjunction, and an epoch is certified only if both pass. The rule carries no conditions. The 26 May 2026 five-of-five result is Demonstrated on Stage 1, on one node. The 11 September 2026 board is an experiment on Stage 2, on one enrolled-write path. The printed conditions and α sit only on step 6, the many-room stacking box. They do not apply to the accept rule at steps 3 and 4. A reject at step 5 never becomes a leaf. The ledger and SIEM hop at step 8 anchors and returns the verdict; it does not decide accept.

Figure B. The same cycle seen as communication, about every thirty seconds. The site hashes the room reading and its own files (C2), signs with the enrolled key and posts over ordinary HTTPS (C3), and the attestation server checks the signature and runs both stages of the accept rule on that same signed pulse: Stage 1, the posterior on this room, then Stage 2, the five classes (C4). On the new Mac lab enroll row, a record verifies only when an ML-DSA-87 signature and the Ed25519 signature both verify over the same record bytes; an Ed25519-only signature is not that row. No name, face, email, or raw media leaves the site. A failed record returns as a reject and is not stored as a leaf (C5). Each site runs its own posterior before any stacking arithmetic is applied across sites (C6). The printed conditions and α sit only on that stacking step. They do not apply to the accept rule at C4. Only a certified record is stored under the Merkle root (C7). The verdict returns to the site, and joining certified state to the customer’s SOC desk is a later hop, not part of how the reading reaches the server (C8).

1.6 Relationship to DTS

This whitepaper is the product and architecture overview for enterprise PR Sentry deployments. Distributed Thermodynamic Security (DTS) names the security category behind the physical and statistical classes: authentic physical-environment signals, cryptographic commitment of attestation artifacts, and participation on widely deployed hardware. Formal model details live in the companion DTS overview, edition 4.4. The Gardner Conjecture, stated there, remains open. The 11 September 2026 attack-surface board is posted on the same Resources page.

2. SEGMENT 0 — ENROLL BEFORE WRITE

2.1 The Ordering Rule

No deployment writes an epoch before it is enrolled. Enrollment binds the deployment identity, sensor roles, and premise map into the enterprise attestation graph. A record from an unenrolled surface is not a certified epoch. Enroll-before-write is the ordering rule for the whole platform, and everything in the sections that follow assumes it has already happened.

An attested location is one site among N. Each location has its own enroll record. The graph at that location covers hardware, software, and AI agents.

2.2 Deployment Identity

Each deployment generates a unique Ed25519 keypair on first execution. That keypair is the deployment identity for its operational life. No two deployments share an identity, even on identical software and hardware. The new Mac lab enroll row also stores an ML-DSA-87 public key beside the Ed25519 public key, and a record on that row verifies only when both signatures verify over the same record bytes. The live pin and the field package still verify Ed25519 only.

The signature satisfies the cryptographic class. It does not, by itself, satisfy the other four.

2.3 Stack Enrollment and the Premise Map

Stack Enrollment registers each witness into the graph with a deployment identity, sensor roles for the Hardware Reality Pulse, a premise map (zone · room · deployment, and rack or asset when the operator enrolls them), and alias bindings used by SOC correlation (hostname, EDR device id, cloud resource name, workload name → Witness ID).

At enrollment, a room signature reference is established from the designated space sensors while the hardware is present in the authorized location. Ongoing Hardware Reality Pulse samples feed the logistical and statistical classes against that signature. Relocation without supervised re-enrollment breaks the match and suspends certified epoch accrual against the prior space until re-binding. This binds Proof of Presence to a defined operational space, not to a movable device instance.

2.4 Enroll Slots Are Not Accept Doors

Hardware, software, and AI agents are signed up on the map at enrollment. They are slots in the record. They are not extra accept doors, and adding one does not add a way to be certified. Human operators are a later slot; this edition does not describe verification of a person’s body identity as a live capability.

2.5 The Software Slot — Software Reality Pulse

The Software Reality Pulse continuously checks the integrity of the platform’s own executable code, configuration, and behavior. It implements the self-attesting property that answers the circular trust problem in §1.1. Its output is an integrity notice, not an accept class.

Enrollment. On first execution, the platform computes the SHA256 hash of all executable binary files in the deployment, computes the SHA256 hash of all configuration files, records the platform version identifier, generates and stores the deployment’s cryptographic identity, and records a signed enrollment reference with the attestation service.

Continuous integrity. At each epoch interval, the Software Reality Pulse recomputes the SHA256 hash of all executable binaries and of all configuration files and compares them to the enrolled hashes. Agreement confirms the files are unchanged since enrollment. A mismatch confirms modification.

A hash miss is a notice, not a sixth class. A hash mismatch is a tamper notice. It does not, on its own, certify or de-certify an epoch, and it does not move the Reality Pulse Meter. The meter counts certified epochs — those that cleared both stages of the accept rule (§10.4). A tamper notice is a signal to the operator and a trigger for the tamper response below. Accept remains the two-stage rule, evaluated by the verifier.

Behavioral integrity. The Software Reality Pulse compares runtime network destinations to a behavioral specification of authorized endpoints. Destinations are obtained by reading the enrolled program’s own open connections; the Mac lab reads them with lsof on that process. Host and port are compared with the signed endpoint list. The lab’s own post of the 30-second record is not counted as that program’s behavior. A destination not on the list is a notice. The notice does not certify the epoch, and it does not by itself reject a record that passed the accept rule. In the Mac lab these notices are stored on that asset’s epoch with certified false.

The self-attesting property. The Software Reality Pulse hashes its own source files along with the rest of the deployment. Any change to the Software Reality Pulse itself shows up as hash drift within one epoch interval. The mechanism checks itself with the same mechanism it provides, within the deployment’s threat model. A same-privilege adversary who can intercept file reads and forge hashes is outside the baseline guarantees (see patent specification Section IV.E). This reduces reliance on blind trust in the vendor’s word for many deployment classes. It does not remove the need for trust in every component of a deployment. A hardware root of trust, kernel integrity, and out-of-band monitoring are complementary where required.

Tamper response. On binary modification, configuration change, or behavioral anomaly, the Software Reality Pulse sets the deployment to KILLED state, ceasing entropy contribution and attestation; records a signed tamper epoch and may emit a SIEM webhook; sends an alert to the enterprise’s configured notification endpoints; logs the event with timestamp and modification details; and declines to resume until manual re-enrollment. The signed tamper record gives a forensic marker for the interval at about 30-second resolution. It is a notice on the record. It is not a certified epoch.

2.6 The AI Slot — AI Reality Pulse

For deployments that run autonomous AI agents, the AI Reality Pulse adds evidence that the agent is authorized, running an approved model, and acting within defined bounds. AI enrollment is not a pre-condition for closing an epoch. Every enrolled agent is a node on the graph with a scope attached.

When an AI slot is enrolled, the AI Reality Pulse verifies that the agent runs under valid authorization credentials in an agent authorization registry, computes a hash of the model or models and compares it to a certified reference hash, and monitors runtime actions against a defined behavioral specification, raising alerts for human review on out-of-bounds operations. Action lines come from the agent itself: an enrolled agent writes its own action lines to a file, and a second process reads that file and compares the lines with the written list. An action not on the list is a notice. An empty or missing action file is a miss, with the reason ai_action_record_missing; it is not treated as inside the list. The notice does not certify the epoch. In the Mac lab these notices are stored on that asset’s epoch with certified false.

Accept can close with no AI. The AI Reality Pulse is not one of the five accept classes. An epoch can be certified with no AI slot enrolled. Where an AI slot is enrolled, the AI Reality Pulse requires the Hardware and Software Reality Pulses to be operating and healthy. An agent whose physical environment cannot be verified, or whose runtime code has drifted, is treated as potentially compromised regardless of AI-layer authorization.

3. SEGMENT 1 — THE SENSOR BANK

3.1 Where the Physical Class Comes From

The Hardware Reality Pulse gathers evidence that the deployment exists in a genuine physical environment, so simulated, virtualized, or spoofed environments can be separated from real ones. The sensors sit outside the compute plane and outside the enrolled graph of the attested location. Nothing running on the monitored host feeds them. That evidence feeds the physical, statistical, and logistical classes. It does not itself decide accept.

3.2 Physical Environment Signals

Visual channel. The platform reads any available optical sensor — IP cameras over RTSP or ONVIF, locally connected cameras, or device webcams. Authenticity evidence is drawn from pixel-level statistical noise caused by quantum photon shot noise and the thermal noise of the sensor array. This noise is physically genuine. It arises from the behavior of individual photons and cannot be synthesized to match the statistics of real sensor output without the actual physical sensor.

For illustrative space-science deployments only, high-energy particle interactions with optical sensors can produce distinctive event statistics. Operational claims are deployment- and calibration-specific.

Acoustic channel. The platform reads any available acoustic sensor — conference systems, building microphones, industrial acoustic sensors, or device microphones. Evidence may come from emitting a known test signal and analyzing the received Room Impulse Response, which encodes the geometry and materials of the space, or from analyzing the spectral entropy and temporal complexity of ambient sound. The Room Impulse Response of a physical space is specific to that space at that time.

Signal quality must meet an internal policy floor for a reading to count. Exact floors are not published in this edition.

Kinetic / motion channel. The platform reads any available motion or vibration sensor. Evidence is drawn from the complexity and non-periodicity of physical motion — organic micro-vibration from air currents, thermal expansion, nearby activity, and environmental dynamics — which is statistically distinguishable from the periodic mechanical patterns of controlled computational environments.

Pre-NDA protection: channel weights, score fusion formulas, accept thresholds, and calibration constants are trade secrets. They are not published here.

3.3 Sensor Compatibility

The Hardware Reality Pulse works with existing infrastructure. No new hardware is required.

4. SEGMENT 2 — THE THIN CLIENT

4.1 Sample, Hash, Sign — No Verdict

The client is thin. About every thirty seconds it samples the enrolled sensors, computes hashes over the evidence and over its own files, and signs the epoch with the enrolled Ed25519 key. On the new Mac lab enroll row the 30-second record also requires an ML-DSA-87 signature over the same record bytes, and it verifies only when both ML-DSA-87 and Ed25519 verify; an Ed25519-only signature is not that row. The Mac lab record server agrees a connection secret with ML-KEM-1024 and X25519, and both halves must succeed or that new row is refused. That is the Mac lab record path only. The live signer and the field package still verify Ed25519 only, and no post-quantum primitive is claimed as built on the live pin. The client does not run the statistical model. There is no Bayesian scoring on the laptop, on premise. This keeps the accept decision off the monitored host.

The client computes a Physical Proof of Liveness (PoL) hash over the sampled evidence:

The PoL commitment is carried in the submitted epoch. Raw channel bytes and internal scores are not required for external disclosure in this edition.

4.2 The Submitted Epoch Record

Protocol	Sensor Type	Use Case
RTSP/ONVIF	IP cameras	Security cameras, server room CCTV
USB Video	Webcams	Workstation cameras, local cameras
MQTT	IoT sensors	Building and industrial sensors
BACnet	Building management	HVAC, environmental monitors
Modbus	Industrial sensors	Vibration, condition monitors
REST API	Cloud sensors	Weather, environmental APIs
USB Audio	Microphones	Local audio input
OS APIs	Device sensors	Smartphone, laptop sensors

At each interval (reference cadence about 30 seconds), the deployment assembles and signs an epoch record. The record carries submitted evidence and claims, not a self-declared verdict.

{
  "deployment_id": "Ed25519_public_key",
  "epoch_id": 14832,
  "timestamp_utc": "2026-04-20T10:32:00Z",
  "submitted": {
    "hardware_pulse": {
      "pol_hash": "sha256_hash_over_sampled_evidence",
      "channels_present": ["visual", "acoustic", "kinetic"]
    },
    "software_pulse": {
      "binary_hash": "sha256_hash",
      "config_hash": "sha256_hash",
      "behavioral_notice": "none"
    },
    "ai_pulse": {
      "enrolled": false
    }
  },
  "signature": "Ed25519_signature_over_all_fields",
  "ml_dsa_signature": "ML_DSA_87_signature_over_the_same_record_bytes"
}

The ml_dsa_signature field is added on the new Mac lab enroll row, beside the Ed25519 signature. On the live pin and in the field package the record carries the Ed25519 signature only.

The device submits evidence. It does not write FULLY_ATTESTED, GENUINE, or HEALTHY as a self-decided outcome. A self-reported “healthy” flag from inside the monitored compute plane is not the win.

4.3 What Leaves the Site

The post is an ordinary outbound HTTPS call to the attestation service. It carries hashes, the enrolled public key, a timestamp, and the signature. It does not carry a name, a face, an email address, raw photographs, or raw audio.

5. SEGMENT 3 — THE ENTROPY AUTHENTICITY POSTERIOR

5.1 What the Posterior Does

The verifier evaluates the submitted environment evidence against the enrolled baseline for that room and returns a posterior — the probability that the reading is genuine given the room features — measured against the policy gate. This is Stage 1 of the accept rule (§1.4). The physical and statistical class bits are set here, on the server. The client does not pre-grade the room and does not decide whether the environment is genuine. Operators see pass, fail, or degrade outcomes and the signed epoch artifacts.

5.2 What Was Demonstrated on 26 May 2026

On 26 May 2026, the production entropy authenticity posterior was run against five scripted forgery classes and one genuine control. All five forgeries carried valid signatures. All five were rejected, including the statistical mimicry frame built so that each modality looked plausible on its own. The genuine control was accepted. Five of five.

This result is labeled Demonstrated on the production entropy posterior. Its scope is exact and worth stating plainly:

What that single node buys when independently certified rooms are stacked is a separate arithmetic statement with its own conditions. It is set out in §8, not here.

6. SEGMENT 4 — STAGE 2: THE FIVE-CLASS AND

6.1 Stage 2 of the Accept Rule

Once Stage 1 has cleared (§5), the NanŌmics verifier evaluates the same signed epoch against five classes:

An epoch becomes a certified leaf only if all five hold in that same signed epoch, and only if Stage 1 held on that epoch as well. The verifier’s certified verdict — not the client’s submitted fields — is what counts. One miss and the record is not certified. No partial credit.

Stage 1 and Stage 2 together are the accept rule. It is a definition of certification, stated without conditions, and the verifier runs it as written.

6.2 The 11 September 2026 Lab Experiment

Stage 2 was exercised on the enrolled-write path in a lab experiment on 11 September 2026. A board of 47 attack-surface cases was run. Forty-five held, meaning the case was rejected or never became a certified leaf. Two honest controls were accepted, as expected. The board ran a stolen enrolled key, a wrong room pin, and a used-epoch replay as separate cases.

This is labeled an experiment on Stage 2, on one enrolled-write path. It is not a Demonstrated result and not a fleet result.

6.3 Clone Detection — What the Board Showed

A copied deployment has a different identity from the original. The interesting case is a stolen key.

In the 11 September board, a stolen enrolled key and a wrong room pin were two separate cases. The stolen key was rejected on the cryptographic class: the signature did not verify against the enrolled public key. The wrong room pin was rejected on the physical class: the environment evidence was not from the enrolled sensors for that room. Neither became a certified leaf. The accept rule covers the harder case the board did not run as one row: a signature that does verify still has to clear the physical, logistical, statistical, and temporal classes in the same epoch, and one miss means the record is not certified.

This is a lab result on enrolled key plus room pin. It is not a claim that the live platform verifies a person’s body identity as a product feature.

7. SEGMENT 5 — THE REJECT BIN

7.1 A Fail Never Becomes a Leaf

A record that misses any class returns as a reject. It does not enter the Merkle tree. The ledger does not advance on a reject. Submitting a high volume of marginal readings does not improve an adversary’s position; each marginal reading is another reject. There is no averaging path by which weak evidence is blended into a certified epoch.

7.2 Attack Resistance by Class

An adversary must clear both stages on the same epoch to forge a certified epoch: this room’s posterior, and all five classes. Single-class attacks land in the reject bin. The lab board (§6.2) exercises representative cases; full rows and the replay command live in the companion evidence report.

Self-attestation tamper. Modify the Software Reality Pulse to report healthy despite tampered code. The modified Software Reality Pulse has a different binary hash than the enrolled reference, so its own next check produces hash drift and fires the tamper notice. The only naive path is to change deployed bits without perturbing hashed bytes, which is incompatible with substantive behavioral change. Elevated-privilege adversaries (kernel interposition over file reads and hashes, hypervisor spoofing of measurement) must be met with complementary controls — hardware roots of trust, out-of-band golden-image verification — as stated in the patent disclosures.

Physical environment simulation. Simulate genuine sensor output to satisfy the physical and statistical classes. Synthesizing statistically indistinguishable photon shot noise for a specific sensor, or a specific room’s Room Impulse Response, in real time, requires resources beyond practical remote-attack economics for most enterprise threat models (Internal estimate — threat-model dependent). Synthesizing genuinely organic micro-vibration requires physical actors in the space, which defeats the purpose of remote spoofing.

Attestation egress tamper. Divert or forge attestation egress to an attacker-controlled endpoint. Egress destinations and manifests sit inside the measured software envelope. Changing them without defeating integrity checks generally produces hash drift versus enrollment and operator notices. Exact allowlist and signing mechanics are release- and SKU-specific.

Replay. Submit a previously captured legitimate epoch record. A replayed epoch is a used epoch. It fails the temporal class: the epoch sequence and timestamp are checked server-side against the freshness window, and a used epoch is rejected.

Key extraction. Steal the deployment private key to fabricate epochs. A stolen key satisfies the cryptographic class only. The fabricated record must still satisfy the physical, statistical, and logistical classes. Without the enrolled sensors in the enrolled room, the environment evidence diverges from the baseline and the epoch is not certified. The 11 September board ran a stolen key and a wrong room pin as separate cases, and both held (§6.3).

8. SEGMENT 6 — THE POSTERIOR BAYESIAN STACK

8.1 Each Room Carries Its Own Posterior

Every enrolled room has its own baseline and its own posterior, evaluated on its own evidence. Stacking is what happens across rooms that are independently certified in the same epoch window: an adversary who wants a stacked forgery must clear every room’s gate at once.

What n rooms costs a faker. At n independent rooms the faker has to pass both stages at each room — that room’s posterior, and the five classes on that room’s signed epoch. The αⁿ figure published below is the many-room posterior bound and is an Internal estimate. There is no separate fleet Demonstrated result for the five-class conjunction: the 26 May posterior result is one node (§5.2), and the 11 September five-class board is one enrolled-write path (§6.2).

8.2 The Printed Ifs

The stacking bound below is stated under three conditions. They are printed here because the bound does not hold without them.

Under those three conditions, joint false-accept across n independently certified rooms is bounded by αⁿ. That bounded-product statement is Theorem A under the printed ifs. It is a statement about the stack. It is a separate statement from the two-stage accept rule, which is a definition and carries no conditions.

8.2b Theorem B

Theorem B is the modeled full sum under printed ifs. It is listed in the companion IACR draft version 1.8. It does not enlarge Theorem A. It does not close the Gardner Conjecture.

8.3 The Arithmetic

α = 0.826 is the published single-node false-accept measured on the statistical mimicry frame against the production path in May 2026. It is deliberately unflattering: it is the rate for the hardest attack in that set, at a single node. α = 0.826 is a stacking input. It is not a pass rate, not a score, and not a product claim.

Independently certified rooms	Joint false-accept bound
n = 100	≈ 5.0 × 10⁻⁹
n = 1,000	≈ 9.6 × 10⁻⁸⁴

At a thousand rooms the bound corresponds to roughly 276 bits of work. That figure is an Internal estimate: arithmetic under condition 3, not a measured thousand-node deployment.

8.4 Three Qualifications

Independence is an engineering obligation, not a gift. It holds only to the extent that enrollment controls keep certified sites distinct and non-colluding, which is why Sybil resistance is a first-class requirement. Monotonicity in n is conditional: adding rooms that are not independent can reduce the bound’s value rather than increase it. And a bound against scripted adversaries is not a bound against adaptive ones. The general claim that these conditions hold against an unrestricted adversary is the open Gardner Conjecture (§16), which this arithmetic does not prove.

9. SEGMENT 7 — MERKLE FUSE

Certified leaves in an epoch window are fused under a single Merkle root. Only certified rows enter the tree. A row that was submitted but not certified does not enter as an accepted leaf.

Across space. Each additional independently certified room is another leaf under one root. Many places in the same window resolve to one number for the set.

Across time. The next pulse adds a new set of certified leaves and a new root. Changing one old leaf invalidates that root and every inclusion proof that used it.

Inclusion is not accept. An inclusion proof shows that a leaf is in the tree. On its own it does not show that a submitted record was certified, and it does not turn a failed row into a pass. Only certified leaves (§6.1) enter the tree as accepted rows.

The 9.6 × 10⁻⁸⁴ figure in §8.3 is the stacked posterior bound. It is not a property of this fuse. The fuse only takes leaves that already cleared the accept rule.

10. SEGMENT 8 — CHAINED LEDGER AND THE RETURN TO THE SIEM

10.1 The Chained Ledger

Each certified root is pinned to the one before it. The longer the chain runs, the more later links a rewrite of an old root has to rebuild. The same chain can be checked from any location against the public write, so no single site holds the only copy of the history.

10.2 Solana Anchoring — Not an Accept Gate

Certified epoch commitments anchor on Solana. The current environment is Solana devnet. Production Solana goes live with the first customer deployment. The Merkle root of certified leaves anchors on chain and supports inclusion proofs. Independent verification uses the signed epoch and the deployment public key.

The Solana write anchors a root that already cleared the accept rule. It is not one of the five classes and it does not decide accept. If the write fails, the certified verdict stands on the verifier’s evaluation and the anchor is retried on the normal path.

10.3 SOC Integration — Additive and Bilateral (PoPTriage)

The verdict returns to the site on the same round trip: certified or reject for that pulse. Joining certified state to the customer’s SOC desk is a later hop, and it is additive. Sentry does not replace a SIEM, an EDR, or a SOC. It snaps onto the existing stack.

Direction	Function
Out	Signed certified epochs · tamper / halt notices (e.g. webhook) · audit export
In	Security alert records from SIEM / SOAR · entity identifiers resolved through the alias registry

PoPTriage time-joins inbound alerts to certified epochs on the enrolled graph, assigns triage priority classes (for example tamper · halt · pulse failure · certified · unenrolled), and emits enrichment that includes pulse evidence and spatial context (zone · room · deployment) when enrolled. Analysts receive independent witness state beside the alert.

10.4 Reality Pulse Meter — Meter on Accept Only

Reality Pulse Meter counts one billable event per certified epoch — an epoch that cleared both stages of the accept rule on the enrolled stack. The meter reads verified certified epochs on the attestation path. It does not read self-reported “healthy” counters inside the monitored compute plane, and it does not move on a tamper notice alone. Stack Enrollment sets the allowlisted Witness set; PoPTriage and audit export consume the same certified graph. Fee schedules and commercial splits are set in enterprise and OEM agreements and are outside the technical scope of this paper.

10.5 The Enterprise Attestation Graph

The graph is a continuously updated, ledger-anchored inventory of enrolled assets and their certified epoch history. Reads run against certified rows. An unenrolled or uncertified surface appears as attention, not as a certified node. An unenrolled alert is not a certified state.

Enrolled applications can check a peer’s certified status before processing a request. An application whose certified status is stale, failed, or absent is isolated within one epoch interval of the status change. The enterprise policy engine enforces coverage requirements, blocks deployment of applications below policy-required attestation levels, and generates compliance reports from attestation history.

11. PRIVACY

11.1 Privacy Architecture

Publishing plaintext attestation records would expose the timing of incidents to competitors, regulators, and adversaries. The platform supports three privacy tiers.

Community (Transparent). Records are published without encryption. For DePIN participants, conservation organizations, and research deployments whose operators choose full public transparency.

Standard (Encrypted). Each certified epoch is encrypted with the operator’s registered public key before publication. Unauthorized parties cannot tell from the public commitment whether an attestation was healthy or failed, or which enterprise it belongs to.

Enterprise (Zero-Knowledge). For the highest-sensitivity deployments, the Enterprise export carries a zero-knowledge proof alongside the encrypted record. The proof is a Schnorr OR proof on Ed25519, made non-interactive by the Fiat-Shamir transform. It is bound to this export’s ciphertext and to this deployment’s one enrolled Ed25519 verifying key. A reader checks the proof against that key and that ciphertext. The proof discloses no raw telemetry and none of the four confidential fields: which deployment the record belongs to, whether the attestation was healthy or failed, when an incident occurred, and which software is monitored. A proof made under any other key does not verify. A valid proof copied onto another ciphertext does not verify. Scoped decryption grants still open the Standard ciphertext for a named auditor, regulator, insurer, or third party. This tier is a disclosure control on the read path. It is not a sixth accept class, and it is not encryption alone, which is the Standard tier. It is not a proof over the accept evaluation; the verifier still runs both stages as described in §5.1 and §6.1, and the accept rule is unchanged.

11.2 Enterprise Confidentiality

Under the Standard and Enterprise tiers, an external observer cannot determine from unauthorized ledger exports the identity of a deployment, whether an attestation was healthy or failed, when an incident occurred, or what software is monitored.

11.3 Auditor and Regulatory Access

Operators may grant scoped decryption access to security auditors under engagement, regulators under legal compulsion, insurers under policy terms, and any third party at the operator’s discretion for a defined scope and period.

11.4 Selective Disclosure

An enterprise proves a specific certified epoch to a third party by presenting the signed epoch and, where applicable, a Merkle inclusion proof against the Solana-anchored root. Inclusion of an uncertified epoch is not an accept (§9).

12. CAPABILITY MANIFEST AND BEHAVIORAL SELF-VERIFICATION

The materials in this section support disclosure-first review of the client-side build. They are a safety and review kit. They are not part of the accept rule. The Capability Manifest, the sandboxed intercept self-test, and behavioral receipts ship in the platform run kit.

12.1 The Capability Manifest

Prior to a release, NanŌmics PBC publishes a signed Capability Manifest with the attestation service. It declares network endpoints, file paths read or written, classes of system calls, sensor types and access methods, maximum external payload sizes, and required OS privileges. It is signed by NanŌmics PBC and bound to the release binary hash, so self-attestation can check that the client build matches the declared bounds.

12.2 Pre-Execution Behavioral Self-Verification

On each deployment, the platform may run a self-verification before acting in the client environment: retrieve and verify the signed Capability Manifest, verify the executing binary hash matches the Manifest, run a sandboxed self-test that intercepts system, network, file, and sensor calls, compare all self-test operations to the Manifest, publish a signed Self-Verification Attestation Record, and notify the enterprise’s monitoring endpoint. This lets a client review platform safety without a full source audit. It is a review aid, not an accept class.

12.3 Continuous Behavioral Receipts

During operation the platform may generate signed Behavioral Receipts for external actions and carry the aggregate hash in the epoch record. These are a record of actions taken. They are not one of the five accept classes.

13. ATTACK SURFACE DECLARATION AND SELF-DEFENSE

This section describes the platform’s self-defense posture. It is not part of the accept rule. The Attack Surface Declaration and the self-defense monitors ship in the platform run kit. Their output is a notice on the record, not an accept class.

13.1 Attack Surface Declaration

The Capability Manifest may include an Attack Surface Declaration listing assessed attack vectors, the mitigation for each, the detection for each, and the response on detection. It is signed by NanŌmics PBC before deployment, giving disclosure-first review of known risks.

13.2 Self-Defense Monitoring

The platform may monitor for exploitation attempts and publish signed Attack Attestation Records: bounds-checked parsing of sensor inputs, certificate pinning on network communications, process-integrity monitoring for injection and hooking, and key-protection monitoring for extraction patterns. Detected events are recorded as notices.

13.3 What This Adds

Self-defense records add accountability and distributed threat signal across deployments without revealing individual enterprise identities. They strengthen the forensic record. They do not change the accept rule.

14. IMPLEMENTATION AND DEPLOYMENT

14.1 Deployment Requirements

14.2 Enterprise Architecture and Retroactive Coverage

The enterprise deployment runs a parent attestation hub that manages coverage of enrolled software. A lightweight child attestation process runs alongside an existing application without modifying it.

For applications that predate deployment, three non-invasive methods are available: an external binary monitor that watches files and behavior through OS-level observation; a container sidecar within the same deployment unit; and OS-level instrumentation that captures system calls, network, and file operations without modifying the monitored binary. For new applications, the platform integrates with CI/CD pipelines to generate Capability Manifests and to enroll child attestation coverage from first execution.

14.3 Partner Witness

Partner Witness is the field and OEM integrator package for running the Software Reality Pulse (and Hardware and AI pulses as configured) on partner and customer hosts across macOS, Linux, Windows, and Docker. The kit enrolls a Witness identity, signs canonical epoch records, posts them for Ed25519 verify-before-store, and supports independent offline signature verification. This package is the field package, not the new Mac lab enroll row: it verifies Ed25519 only. Premise map enrollment enables PoPTriage spatial context at SIEM ingest. Partner Witness does not replace the customer’s SIEM or EDR; it is the additive outside-compute witness those tools correlate with.

14.4 Sensor Configuration

Operators enroll available cameras, microphones, and motion sensors via supported protocols (RTSP/ONVIF, USB, MQTT, BACnet, Modbus, OS APIs, and similar). Exact configuration schemas ship with the integrator kit under engagement.

15. LICENSING

NanŌmics PBC releases the Physical Reality Sentry Platform under the NanŌmics Protocol License v1.0. Standard and Enterprise tier usage requires protocol fee payment per certified epoch. Core integrity components (including Software Reality Pulse measurement surfaces) may not be modified in licensed deployments.

Enterprise licensing and OEM Stack Enrollment — platform licenses, Reality Pulse Meter terms, integration with security platforms and cloud providers, and bespoke enterprise terms — are available under engagement at nanomics.io (contact info@nanomics.io).

16. RESEARCH FOUNDATION — DTS AND THE SEPARATE CLAIMS

16.1 Distributed Thermodynamic Security (DTS)

DTS is NanŌmics PBC’s name for a security architecture class: authentic physical-environment signals from widely available sensors, cryptographic commitment of epoch artifacts, and deployment on consumer-grade hardware, combined so that authenticity does not rest only on vendor word inside the monitored stack.

16.2 Three Claims, Kept Apart

This paper keeps three claims separate. Collapsing them is the most common misreading, so they are set out here side by side.

Claim 1 — the accept rule. An epoch is certified when both stages pass on that epoch: Stage 1, this room’s posterior against the quality and matching gates, and Stage 2, physical AND cryptographic AND logistical AND statistical AND temporal. It is a definition. It states no conditions, it is not derived from assumptions, and no proof is offered for it. A mechanized check confirms the Stage 2 conjunction is evaluated as written, which confirms the definition and nothing more. The named lemmas behind that Stage 2 check, and the checker result, are listed in the companion IACR draft version 1.8; they do not close the Gardner Conjecture of Claim 3. The 26 May 2026 result is Demonstrated on Stage 1, on one node (§5.2). The 11 September 2026 board is an experiment on Stage 2, on one enrolled-write path (§6.2).

Claim 2 — the stacking bound. Joint false-accept across n independently certified rooms is bounded by αⁿ. That bound is Theorem A under the printed ifs, and the ifs are printed once, in §8.2. It is a statement about the posterior stack and about nothing else in this paper. Theorem B — the modeled full sum under printed ifs — is listed in IACR 1.8 and does not enlarge this claim. The thousand-room figure of about 9.6 × 10⁻⁸⁴ is an Internal estimate under those conditions. The 26 May 2026 five-of-five result is Demonstrated on the single-node posterior that feeds this arithmetic (§5.2).

Claim 3 — the Gardner Conjecture. The Gardner Conjecture claims adversary advantage tends to vanish as honest participation, time depth, and cryptographic strength grow. It remains open until peer-reviewed proof. Neither Claim 1 nor Claim 2 proves it. Theorem A and Theorem B, as listed in IACR 1.8, do not close it. It is not proved in this paper.

16.3 DTS Elements and Sentry Implementation

DTS is not claimed as a finished mathematical theorem. Sentry is the commercial embodiment of the DTS category. This paper specifies the enrolled-write API on which the accept rule is evaluated.

16.4 Outside This Whitepaper

DTS element	Sentry implementation
Physical environment authenticity	Hardware Reality Pulse — enrolled space sensors · Stack Enrollment room signature
Policy-bound accept	Verifier two-stage evaluation — room posterior, then five-class conjunction (scoring internals not published)
Cryptographic commitment	Signed certified epochs, Merkle root committed on Solana (devnet today; production with first customer deployment)
Spatial binding	Premise map zone · room · deployment (rack/asset when enrolled)
SOC bilateral integration	PoPTriage alert correlation · outbound tamper webhook
Certified continuity meter	Reality Pulse Meter on certified epochs
Field / OEM witness	Partner Witness (macOS · Linux · Windows · Docker)
Empirical adversary testing	Production posterior battery (26 May, Demonstrated) · enrolled-write five-class board (11 Sep, experiment)

Beacon and global entropy-network design, and proprietary scoring weights, thresholds, likelihood models, and calibration corpora, are outside the scope of this document. See the companion DTS overview, edition 4.4 for the security-model summary.

17. INCIDENT LANDSCAPE AND PoP COUNTERMEASURES

17.1 The Reporting Gap

Public breach disclosures represent a small fraction of real compromise. Industry benchmarks (Demonstrated — IBM Cost of a Data Breach; Verizon Data Breach Investigations Report) show multi-month mean lifecycles (about 241 days globally in recent IBM editions) and majority discovery by third parties rather than internal teams. Mandatory disclosure regimes capture material incidents; small and mid-market organizations, paid ransom events, and undetected dwell time form a larger unreported mass below public headlines.

NanŌmics planning model (Internal estimate): visible major incidents in a period may represent roughly one unit of a three-to-five unit real incident base in the same economy, with additional unknown exposure still in dwell. This document does not claim census accuracy. It motivates continuous attestation as a discovery-time intervention on enrolled infrastructure.

17.2 Archetypes Addressed

Archetype	Primary gap in conventional stack	PoP response
Supply chain / trojanized update	Code signing proves build-time trust, not runtime integrity	Software Reality Pulse — hash drift → tamper notice ≤30s
Security-product compromise	Circular trust in the vendor binary	Self-attesting Software Pulse includes its own measuring surface
Identity / session / token abuse	IdP proves credential, not physical runtime of the agent	Logistical + statistical classes; AI slot gated on HW+SW health
Cloud SaaS tenant compromise	Tenant logs without an enrolled integrator graph	Stack Enrollment + policy engine on covered workloads
Ransomware / long dwell	Detection after lateral movement	Tamper notice → cross-application trust isolation
Insider / privilege abuse	Authorized user exfiltration	Behavioral receipts plus scoped decryption grants to a named auditor, regulator, insurer, or third party. Each grant ends when the period ends
Physical access fraud	Badge ≠ physics-bound identity	Facility pulse. A badge is not access. The badge must be enrolled to that room, and that same signed epoch must clear both stages of the accept rule. Badge alone fails, the wrong room fails, and a used epoch fails. Not a sixth class, and not a claim that the platform identifies a person’s body
OT / edge / robotics	IT-originated foothold on unmonitored edge	Hardware Reality Pulse + edge Stack Enrollment

Honesty bound: PoP does not eliminate social engineering or all zero-day exploitation. On enrolled surfaces it reduces blind-trust periods, produces ledger-capable forensic timestamps, and supports automated peer isolation when a certified state fails.

17.3 Illustrative Reported Incidents (Selection)

These public incidents illustrate gaps the architecture targets. Strength of countermeasure varies by deployment mode and enrollment scope.

17.4 Vertical and OEM Alignment

Enterprise industry skins (robotics, fintech, healthcare, education, manufacturing, critical infrastructure, transport) reuse the same attestation column with domain-specific emphasis. OEM licensing lets EDR, IdP, MDR, cloud, development-chain, and OT vendors answer customer RFPs requiring continuous Physical Reality proof without multi-year internal R&D.

18. CONCLUSION

NanŌmics PBC (Delaware) presents the Physical Reality Sentry Platform as an integrated architecture for continuous multi-dimensional attestation outside the compute plane, additive to SIEM, EDR, and identity stacks, with Stack Enrollment spatial binding, bilateral SOC triage (PoPTriage), and Reality Pulse Meter continuity on certified epochs.

The accept rule has two stages. Stage 1 is the posterior on the room the witness sits in, against a quality gate and a matching gate. Stage 2 is the five-class conjunction: physical AND cryptographic AND logistical AND statistical AND temporal on that same signed epoch. An epoch is certified only when both pass. The rule is the definition of certification and the paper states it without conditions. The posterior stacking bound is Theorem A, the separate statement that carries printed conditions, and it sits in §8.2. Theorem B is the modeled full sum under printed ifs, listed in IACR 1.8 and named in §8.2b. The Gardner Conjecture is a further claim and remains open.

On evidence: the 26 May 2026 production posterior result is Demonstrated on Stage 1, on one node. The 11 September 2026 board of 47 cases is an experiment on Stage 2, on one enrolled-write path. The thousand-room stacking figure is an Internal estimate.

Readers should evaluate claims against deployment threat models, verifier specifications, and release notes, in addition to the patent-filed disclosures.

REFERENCES

Marks used in this document (™ on first prominent use): NanŌmics · Physical Reality Sentry Platform · Hardware Reality Pulse · Software Reality Pulse · AI Reality Pulse · Reality Pulse Meter · Proof of Presence · PoPTriage · PoP Certified.

Incident (reported)	Class	Relevant pulse / enterprise mode
SolarWinds Orion (2020)	Supply chain via trusted security update	Software Reality Pulse + enterprise child coverage
MOVEit / 3CX (2023)	Vendor binary trojan	CI/CD proactive enrollment; binary monitor
Okta support / Snowflake tenants (2023–24)	Identity and cloud tenant	Integrator enrollment; identity-provider embed
Change Healthcare (2024)	Ransomware / long dwell	Early tamper notice; GRC evidence export
Colonial Pipeline (2021)	IT-to-OT lateral movement	Edge HW pulse on enrolled OT gateways
Anthropic agent sandbox opacity (2026 ack.)	AI runtime invisible to EDR	HW+SW+AI evidence vs logs alone

Individual inventor attribution remains with named patent filings where applicable.

PHYSICAL REALITY SENTRY PLATFORM™