Human and Machine Readable State Parity

A human-readable state view should carry the same operational meaning as its machine-readable source. We would test rendering as a transformation with its own failure modes. A correct API response can still produce a misleading explanation when labels, units, or qualifiers change on the way to the owner or model.

Our state and memory framework provides typed decision inputs and provenance. Our trace feedback method helps locate whether a disagreement began in state assembly, rendering, or later reasoning. This note concentrates on the rendering boundary.

The label changes the balance

Take an illustrative typed record with total_cash 600, reserved_cash 100, and available_cash 500, all in the same currency. A readable card saying “Cash available: 600” is wrong even though 600 appears in the source. A card saying “Cash: 600; 100 reserved; 500 available” preserves the relationship and supports a clear owner review.

A model-facing sentence can make the same error. “The account has 600 to trade” changes the semantics of total cash into an allocation claim. We would audit both the owner display and the text actually sent to the model, rather than assuming one shared component guarantees parity across surfaces.

Null handling provides a second case. A missing liquidation-price estimate should render as unavailable with the source status. Converting null to zero can create a precise-looking price with no evidence. An empty string may disappear entirely, leaving a reader unable to tell whether the field was unknown or omitted by design.

Compare meaning in both directions

The proposed test starts with a typed fixture and expected readable claims. A deterministic extraction checks values, units, and labels in the rendered output. A human review checks relationships that a simplistic number matcher misses. The reverse step reconstructs the required typed claims from the readable view and compares them with the original fixture.

The test includes negative balances, small quantities, and estimated values. Rounding is permissible only under a declared display rule, and the exact operational value must remain available where an action depends on it. An estimated value should retain its estimate label even when it shares a numerical format with a verified ledger amount.

We would measure field coverage, value agreement, and semantic agreement separately. A display can include every field and still swap total with available. It can copy every number while dropping the currency. It can be semantically correct yet hide a required field behind a collapsed panel that the model never receives. Delivery and meaning each need evidence.

The protocol applies to proposed interfaces and carries no guarantee about DXAP's current renderer. Its useful acceptance artifact is a side-by-side view with the typed record, owner display, and model input for one decision. When those views disagree, the repair should name the changed meaning. That gives an owner a concrete explanation for a confusing answer and lets the builder fix the transformation that caused it, rather than treating presentation as harmless decoration.