AN—001 ARCHITECTURE NOTE · PUBLISHED 2026-05-14

Physics validation as a non-bypassable gate

How constraint sets are assembled per asset class, how they are evaluated, what is recorded when they fail — and how a constraint that is itself in dispute is handled without stopping the plant.

READING TIME 3 MIN · IMPLEMENTATION DETAIL · SUPERSEDES NOTHING

1 — WHAT THE GATE IS FOR

A recommendation that has not been checked against the asset's physical limits is a suggestion, not an engineering output. The gate exists so that the check cannot be skipped — not by a configuration flag, not by an urgent override, not by an agent that has learned the check usually passes.

Every path from a model to an engineer runs through PhysicsNET. There is no second path. This is an architectural property rather than a policy, because a policy has an exception process and physics does not.

2 — HOW A CONSTRAINT SET IS ASSEMBLED

Constraints are assembled per asset, not per asset class, though the class supplies the starting set. Assembly runs in four passes and the result is pinned to the revision of every document it drew from.

PASS 1Class constraints — what any centrifugal chiller must satisfy

PASS 2Design basis — this unit's nameplate, curves and datasheet limits

PASS 3Site amendments — derates, temporary restrictions, standing exceptions

PASS 4Regulatory overlay — statutory limits that no site amendment may relax

Later passes may tighten a constraint and may never widen one, with a single exception: a site amendment may widen a class default where the design basis explicitly supports it. That exception is recorded with the clause that justifies it.

3 — EVALUATION

Evaluation is deterministic and total. Every constraint in the set is evaluated on every proposal — there is no short-circuit on first failure, because an engineer needs to know all the ways a proposal is wrong, not the first one found.

Quantities carry units through evaluation. A comparison between incompatible dimensions fails at parse time rather than producing a silently wrong verdict; that mechanism is described in AN—003.

4 — WHAT IS RECORDED ON FAILURE

A block is an engineering event, not an error. The record is written whether or not anyone looks at it, and it is queryable — a recurring block against one asset is usually a finding about the asset, and occasionally a finding about the constraint.

// block record · fields

constraint_id which limit, at which revision

margin how far outside, in the constraint's own units

proposal_source which agent, which model version

inputs_hash exact inputs, for reproduction

disposition shown to whom, and what they did next

5 — CONSTRAINTS THAT ARE THEMSELVES IN DISPUTE

Sometimes the limit is wrong. A datasheet value transcribed from the wrong variant, a derate that was never lifted after the repair, a class default that does not apply to this configuration. If the gate treated every constraint as settled, the practical result would be engineers routing around the system.

So a constraint may be marked DISPUTED by a responsible engineer, with a written basis. A disputed constraint still blocks — the gate does not weaken — but the block is labelled as resting on a contested limit, and the dispute enters the review queue with the asset's evidence attached. Resolution changes the constraint or closes the dispute; nothing is resolved by timeout.

This is the one place where the architecture deliberately accepts friction. An engineer who believes a limit is wrong must say so in writing, on the record, under their own name — which is a higher bar than an override button and a lower bar than silence.

PhysicsNET — the capability page EP-WP-001 §5 — Principle III EP-WP-002 — ontology scope, in drafting

How to cite this note

ENGINPILOT (2026). Physics validation as a non-bypassable gate. Architecture Note AN—001. Bengaluru: ENGINPILOT Intelligence Systems.

All architecture notes