On this page
RNX code library · 17 controls
RNX-340Commerce, Negotiation & Audit
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-341 · ACP Integration
RNX-341.T001
ACP partner eligibility evidence
core readiness
For a partner commerce integration, verify actual approval and the merchant's working path.
Why it matters. Publishing a sample feed does not establish partner eligibility.
Illustration — fictional. Application submitted is called production approval.
When it applies. Inspected target: partner onboarding. 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-341.T002
Named commerce protocol lifecycle
Experimental — not an established ranking requirement
Follow the states and rules of the named commerce protocol version.
Why it matters. A partial integration should not claim unsupported transaction features.
Illustration — fictional. A product's feed eligibility is treated as proof that checkout was completed.
When it applies. Inspected target: commerce lifecycle. 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-341.T101
Supported OpenAI feed schema selection
core readiness
For an OpenAI commerce feed, select the supported format for the actual integration.
Why it matters. Similar-looking schemas are not interchangeable contracts.
Illustration — fictional. An integration sends fields supported only in a draft format to the production feed.
When it applies. Inspected target: schema configuration. 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-341.T102
OpenAI discovery row completeness
core readiness
Include the required discovery information in each applicable OpenAI feed row.
Why it matters. A product cannot be reliably understood from missing essential fields.
Illustration — fictional. Availability blank is assumed in stock.
When it applies. Inspected target: discovery row. 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-341.T103
OpenAI variant identity tuple
core readiness
Preserve the required combination of identifiers for an OpenAI product variant.
Why it matters. Confused identity can attach one version's facts to another.
Illustration — fictional. A variant repeats its group identifier as its own identity, confusing the group with the individual item.
When it applies. Inspected target: variant row. 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-341.T104
OpenAI optional unknown representation
core readiness
Represent unknown optional feed values as the contract requires.
Why it matters. Empty guesses should not become invented product facts.
Illustration — fictional. Unknown weight submitted as zero.
When it applies. Inspected target: optional feed value. 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-341.T105
OpenAI market setup boundary
core readiness
Separate OpenAI market setup from ordinary row data.
Why it matters. A country written in a product row does not by itself establish market enablement.
Illustration — fictional. Adding a Canada field to a product row is treated as completing the provider's market setup.
When it applies. Inspected target: market declaration. 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-341.T106
OpenAI snapshot shard continuity
core readiness
For a split catalog snapshot, preserve continuity across its pieces.
Why it matters. Missing or mismatched pieces can leave an incomplete catalog.
Illustration — fictional. Every catalog upload gets a new name, leaving old snapshots where the integration still reads them.
When it applies. Inspected target: snapshot delivery. 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-341.T107
OpenAI product removal semantics
core readiness
Use the integration's supported product-removal meaning.
Why it matters. A removed item should not remain offered because deletion was described incorrectly.
Illustration — fictional. Omitted product claimed removed immediately despite retention window.
When it applies. Inspected target: removal event. 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-341.T108
OpenAI scheduled-state misconception prevention
core readiness
Do not assume a future price or stock value schedules itself.
Why it matters. Updates must follow the actual integration's timing rules.
Illustration — fictional. Expired sale remains current because no new price snapshot is sent.
When it applies. Inspected target: price or stock update. 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-341.T109
OpenAI product readback units
core readiness
Interpret returned product prices in the documented units.
Why it matters. Confusing cents with dollars changes the offer dramatically.
Illustration — fictional. A returned price of 1,800 cents is interpreted as 1,800 dollars instead of 18 dollars.
When it applies. Inspected target: readback price. 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-341.T110
OpenAI checkout enablement scope
core readiness
Check the actual scope of OpenAI checkout enablement.
Why it matters. Being discoverable as a product does not automatically enable purchasing through that interface.
Illustration — fictional. A checkout-eligibility field is treated as proof that required partner onboarding has been completed.
When it applies. Inspected target: checkout eligibility. 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-342 · Immutable Audit Trails & Task IDs
RNX-342.T001
Transaction audit correlation
Experimental — not an established ranking requirement
Make authorized transaction review possible without retaining unnecessary sensitive details.
Why it matters. A clear trail helps explain what happened and who approved it.
Illustration — fictional. Receipt cannot be tied to approved request.
When it applies. Inspected target: transaction trace. 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-343 · Deterministic Arbitration Hierarchy
RNX-343.T001
Conflicting instruction refusal
Experimental — not an established ranking requirement
Resolve conflicting instructions according to the authorized policy.
Why it matters. Outside text must not grant itself permission to change the rules.
Illustration — fictional. Instructions inside retrieved content cause an unauthorized export of private information.
When it applies. Inspected target: instruction conflict. 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-344 · Transaction Confirmation States
RNX-344.T001
Confirmation state authorization
Experimental — not an established ranking requirement
Allow action only from the properly approved state.
Why it matters. Showing a quote is not proof of consent or payment.
Illustration — fictional. Quote retrieval creates order.
When it applies. Inspected target: confirmation 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-345 · Non-Repudiation Signatures
RNX-345.T001
Signed transaction tamper rejection
Experimental — not an established ranking requirement
For signed transaction messages, detect altered copies.
Why it matters. Otherwise a changed instruction may look authentic.
Illustration — fictional. A signed ten-dollar instruction is altered to one hundred dollars and still accepted.
When it applies. Inspected target: tamper 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-346 · Agentic Deadlock Escalation Protocol
RNX-346.T001
Bounded negotiation termination
Experimental — not an established ranking requirement
End automated negotiations at a stated bound, with an honest unresolved result when needed.
Why it matters. Systems should not bargain forever or invent agreement.
Illustration — fictional. Two automated services keep negotiating without a stopping rule.
When it applies. Inspected target: negotiation 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.