# MUJ428 Decision Delta Test

Keep your current policies, wallet, filters, reputation checks and authorization controls. Evaluate one action in shadow mode: does MUJ428's preflight identify an actionable gap or produce a receipt that measurably improves your review? If it duplicates what you already know, or its cost exceeds its usefulness, do not add the dependency.

This is an evaluation of the existing Trust Reflex, not a new product or decision engine or a requirement to migrate policy ownership.

## External architectural precedent

Separating decision logic from workflow execution is an established pattern. [OMG's Decision Model and Notation](https://www.omg.org/spec/DMN/) supplies a decision-modeling standard. However, existing systems can already implement that separation: [Open Policy Agent](https://www.openpolicyagent.org/docs) explicitly separates policy decisions from enforcement and accepts structured inputs, with [decision logging](https://www.openpolicyagent.org/docs/management-decision-logs).

More concrete pre-execution precedents also exist in agentic commerce:

- [Mastercard Agent Pay for Machines](https://www.mastercard.com/us/en/news-and-trends/press/2026/june/mastercard-launches-agent-pay-for-machines.html) describes a partner trust layer adding real-time transaction-level risk assessment, Know Your Agent verification and traceability across the payment lifecycle.
- [Visa Trusted Agent Protocol](https://developer.visa.com/use-cases/trusted-agent-protocol) binds trust to a specific operation and uses time-sensitive signed data to prevent relay/replay and establish current authorization.
- [Google AP2](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) uses signed Intent and Cart Mandates as transaction-specific evidence linking user intent to payment.
- [Microsoft Agent Governance Toolkit](https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/) reports sub-millisecond policy enforcement designed to intercept agent actions before execution.

These are external examples of last-mile, action-bound controls and evidence. They still do not prove MUJ428's incremental effectiveness for a specific operator. They do not prove that a customer needs another service. A shared service also does not guarantee identical results unless the inputs, policy/data versions and relevant time context are controlled. Receipt schema version 1.3 is not a pinned decision-policy version.

## Smallest useful comparison

1. Choose one operator-owned decision boundary and freeze your existing decision before requesting MUJ428. Record the native result, its mapping to ALLOW / VERIFY / REQUIRE_VERIFICATION / DENY, the policy version or commit, and reasons. Predeclare what useful additional information would change a real decision or reduce review work, what would reject the integration, and the latency budget. Include existing all-clear cases and known problem cases in subsequent sampling; do not select only cases favorable to MUJ428.
2. Review exactly which data will leave your runtime. Download the [comparison example](https://agents.muj428.com/examples/compare-trust-preflight.mjs), create a local case from the template below, and preview it with Node 22 or later. The preview makes no request. The optional `--send` makes one request to the canonical free preflight endpoint, with no payment handler, wallet, executor, automatic retry or recursive verification.
3. The operator independently judges the result using their existing evidence and outcome records. Record useful new information, duplication, false alarms, unnecessary holds, latency, integration/review minutes and receipt usefulness. Request a distinct second case only after the operator finds the first useful. A synthetic safety check alone does not demonstrate commercial value.

```sh
node compare-trust-preflight.mjs case.json
node compare-trust-preflight.mjs case.json --send > comparison.json
```

Template: replace the illustrative identifiers, baseline and criteria with your own. `max_latency_ms` is intentionally `null`; the operator must set its own positive latency budget before running the evaluator. MUJ428's internal release margin is not a customer SLA. The sample is synthetic, not customer evidence. Keep disclosure_reviewed false until you have reviewed the preview. Do not include secrets, private keys, credentials or confidential customer evidence. The example does not redact data or establish a retention agreement.

```json
{
  "schema_version": "1",
  "case_ref": "your-evaluation-case-001",
  "disclosure_reviewed": false,
  "request": {
    "caller_ref": "your-stable-operator-id",
    "action_ref": "your-distinct-event-001",
    "action": "TRUST",
    "actual_arguments": {"subject": "synthetic-evaluation-target"},
    "amount_usd": 0,
    "irreversible": false,
    "evidence": []
  },
  "baseline": {
    "decision": "ALLOW",
    "native_decision": "illustrative-existing-result",
    "policy_ref": "your-policy-version-or-commit",
    "reason_codes": []
  },
  "evaluation": {
    "case_origin": "synthetic",
    "question": "Does this preflight add information our controls do not already provide?",
    "success_criterion": "Operator substantiates an actionable gap or measured review-time saving",
    "rejection_criterion": "Only repeats known signals, creates an unjustified hold, or exceeds our latency budget",
    "max_latency_ms": null
  }
}
```

The example sends only the `request` object. Baseline decisions, policy references and evaluation criteria remain in your local report unless you share it. Values inside `request` are disclosed to MUJ428. Its field allowlist is intentionally limited; unsupported fields produce an error rather than silently changing the test. Preserve the same action_ref for the same event; a replay is not invocation #2. A genuinely different event needs a distinct action_ref.

## Material-value gate

For MUJ428's current P0, **material VALUE is the primary success condition**.

- `VALUE`: the independent preflight changes or strengthens a real decision for a defensible reason the operator considers actionable, such as a justified hold/block, a surfaced stale/conflicting/missing condition, or a measured reduction in decision-review work.
- `AGREEMENT_WITH_PROOF_VALUE`: the systems agree and the Trust Receipt is useful for audit, portability, dispute handling, or post-incident review. This is a positive secondary signal, **but it does not by itself satisfy the current P0 or justify recurring dependency**.
- `NO_FIT`: the same-evidence comparison adds no useful judgment or proof, or the latency/effort/dependency cost exceeds the benefit.

Do not frame a receipt-only agreement as if MUJ428 caught something the existing stack missed.

## After value: progressive adoption

Do not jump from a useful shadow result directly to hard dependency. Use one operator-controlled progression for the selected consequential action class:

**SHADOW → ADVISE → GATE → DEFAULT**

- **SHADOW:** MUJ428 runs beside the native decision and has no execution effect.
- **ADVISE:** the decision and Trust Receipt are surfaced as advice; the native policy remains authoritative.
- **GATE:** after material value and a voluntary distinct #2, the operator may configure its own policy to require an acceptable fresh MUJ428 preflight for selected action classes.
- **DEFAULT:** after recurring value, receipt/action binding verification, failure-policy testing and explicit operator approval, MUJ428 becomes the default preflight route for the selected action class. The customer's system still retains execution authority.

Promotion is never silent or automatic. Software may say that evidence is sufficient for the operator to review the next mode, but it must not change the mode, expand protected action classes, authorize execution or start paid continuation by itself. Material false alarms, receipt/binding mismatch, sustained latency above the operator's budget, availability behavior inconsistent with the customer's failure policy, or revoked opt-in are review/demotion triggers.

Machine-readable contract: [progressive-adoption.json](https://agents.muj428.com/progressive-adoption.json). Runnable reference wrapper: [progressive-trust-adoption.mjs](https://github.com/wmujahid428-web/muj428-a2a-revenue-engine/blob/main/examples/protocols/progressive-trust-adoption.mjs).

## Two distinct kinds of delta

Keep these separate:

1. **Decision-logic delta:** both systems receive materially the same pre-action evidence, but apply independently maintained decision logic. A disagreement can be useful, but must be adjudicated; stricter is not automatically better.
2. **Evidence-verification delta:** MUJ428 or a separately invoked evidence capability obtains/verifies evidence the caller's existing stack did not independently establish. Only this category supports claims that MUJ428 surfaced a new external fact.

The free Trust Reflex evaluates supplied context/evidence indicators. It does **not** independently prove every factual claim submitted by the caller. Do not describe a caller-supplied `evidence_state` as independently verified merely because MUJ428 returned a decision.

## Operator-ready cases

The following cases are pre-packaged to reduce evaluation work. They remain synthetic templates until the named operator replaces placeholders with its own reviewed evidence and independently runs or validates the case.

- [apix402 bounded x402 PAY case](https://agents.muj428.com/examples/decision-delta/apix402-pay.json)
- [openclaw-chile paid endpoint freshness case](https://agents.muj428.com/examples/decision-delta/openclaw-chile-endpoint.json)
- [SantaClawd scoped PAY-safety case](https://agents.muj428.com/examples/decision-delta/santaclawd-pay-safety.json)
- [External precedent and evidence map](https://agents.muj428.com/docs/DECISION-DELTA-EVIDENCE.md)



| Observation | What it establishes | What still requires independent review |
| --- | --- | --- |
| AGREEMENT | Both returned the same mapped decision | Whether the receipt reduced review effort or added useful detail |
| DISAGREEMENT | The mapped decisions differ | Which answer is justified; a stricter decision can be a false alarm |
| Additional reason codes | Different reason labels appeared | Whether they represent new, accurate, actionable information |
| CONTRACT_MISMATCH | Expected identity, argument binding or no-charge fields did not match | Investigate before relying on the response |
| UNAVAILABLE | The observation could not be completed | Dependency reliability and your existing failure policy |
| STOPPED_PAYMENT_REQUIRED | The endpoint returned HTTP 402 | Stop; this is neither a payment nor permission to pay |

This harness never applies a decision to your workflow. Keep the caller's existing controls, security boundaries and failure policy. The report checks receipt identity, action, argument digest and runtime no-charge fields, but is not an authenticated receipt verifier. Its SHA-256 digests are content checks, not signatures or proof of external operator control.

## Limits to test honestly

The free preflight evaluates supplied context and evidence indicators. It does not independently establish the truth of every submitted claim. Its heuristic risk score is not a calibrated loss probability. A free receipt does not grant execution authority. Neither free ALLOW nor the zero-money template authorizes another tool to act. Separately authenticated execution-receipt enforcement is a different integration step.

One observation measures one latency sample, not a percentile or a reliability guarantee. A historical case can support retrospective evaluation; it cannot prove a prevented loss. A synthetic case can demonstrate integration behavior; it cannot establish independent customer adoption. The tool leaves incremental_value as UNASSESSED and external adoption/control as unverified in every report.

For any proposed benefit, retain a reviewer record: case_ref, baseline policy reference, request hash, receipt ID, operator-controlled invocation evidence, reviewer identity, evidence supporting the adjudication, usefulness or no-fit finding, review minutes, and whether a second distinct case is wanted. Share only a reviewed subset through the existing conversation. Do not infer independent control from a caller_ref alone.

## Proceed or stop

Proceed only when the operator confirms a benefit exceeding the extra latency, integration effort, review burden and dependency risk. If the same evidence and outcome were already available, record NO-FIT / no incremental value. If useful, test another independently chosen event and then evaluate repeat use before changing production dependence.

Current terms: [canonical pricing](https://wepmhfjzckclvywolrek.supabase.co/functions/v1/trust-layer/pricing.json). This evaluator requires a zero-charge response and never starts a paid continuation.