On this page
RNX code library · 6 controls
RNX-330Functional Utility & Live Data
Read what these checks mean, why they matter and which evidence they concern. Each ID below keeps its canonical place in the RNX hierarchy.
These are free learning summaries, not full technical tests or an industry certification. Specialized checks apply only to the relevant feature. Experimental labels are preserved from the canonical source.
RNX-330.T001
Operational fact freshness state
Experimental — not an established ranking requirement
Distinguish current, stale and unknown operational facts.
Why it matters. An old stock count should not authorize a confident current promise.
Illustration — fictional. Expired price returned as currently valid.
When it applies. Inspected target: freshness assertion. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-331 · Semantic Tool-Calling Metadata
RNX-331.T001
Tool argument schema rejection
core readiness
Reject tool inputs outside their allowed structure before taking action.
Why it matters. Unexpected inputs should not produce unintended changes.
Illustration — fictional. A tool accepts a wrongly formatted amount and bypasses the intended spending limit.
When it applies. Inspected target: argument rejection. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-332 · Real-Time State Heartbeats
RNX-332.T001
Missed-event recovery
Experimental — not an established ranking requirement
Recover current state or missed events after an interruption.
Why it matters. A reconnecting client should not claim it stayed current throughout the outage.
Illustration — fictional. A reconnecting client misses a cancellation and continues treating the order as active.
When it applies. Inspected target: resynchronization. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-334 · Deterministic Response Contracts
RNX-334.T001
Unknown response contract
Experimental — not an established ranking requirement
Give unknown results a clear, separate meaning.
Why it matters. Missing information must not look like a successful factual answer.
Illustration — fictional. Missing stock becomes zero without unknown marker.
When it applies. Inspected target: unknown-result fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-338 · Verified State Assertions
RNX-338.T001
Expired state assertion rejection
Experimental — not an established ranking requirement
Reject or clearly mark expired state information.
Why it matters. An old permission or availability statement may no longer support an action.
Illustration — fictional. An expired statement is accepted as current merely because its signature is valid.
When it applies. Inspected target: expiry fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-339 · Resource-Constrained Execution Policies
RNX-339.T001
Execution budget enforcement
Experimental — not an established ranking requirement
Stop automated work at its declared limits and keep a recoverable state.
Why it matters. An unbounded task can waste resources or leave partial actions unclear.
Illustration — fictional. An automatic retry loop keeps running after its budget is exhausted.
When it applies. Inspected target: budget fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.