● Red team it

Watch it refuse a malicious payment screen.

A model can emit a wrong payment screen for reasons you can't prevent, an injection, a poisoned tool result, or a plain hallucination. This isn't about stopping the attack; it's about not trusting the output. Below, the same agent emitted surface renders two ways: a naive generative UI renders whatever it's given, Catalystic UI verifies it first and rejects any tampered or invented confirmation before it reaches the user.

Naive generative UI renders whatever the agent emits

Catalystic UI verified at render

Not a hope, a guarantee

Why it cannot render a tampered payment

It doesn't matter whether the bad surface came from an injection, a poisoned tool, or a plain hallucination. Consequential components are a strict, closed contract: a tampered or invented confirm can't validate against it, and a consequential failure is rejected, never repaired. Enforced on every render, by construction, not by luck.

"ConfirmSheet": {
  "x-consequential": true,                 // this component is enforced, not repaired
  "properties": {
    "component":    { "const": "ConfirmSheet" },
    "kind":         { "enum": ["payment", "transfer", "generic"] },
    "currency":     { "enum": ["GBP", "USD", "EUR"] },   // "BTC" can't pass
    "confirmLabel": { "type": "string" }
  },
  "required": ["confirmLabel"],            // the confirm action can't be stripped
  "unevaluatedProperties": false       // no injected props (e.g. "autoApprove")
}

// runtime failure policy
consequential + invalid  →  REJECT   // never coerce, never render
nonconsequential + bad  →  repair    // tolerance is fine here

Catalystic UI enforces the fixed structure of consequential components (payment, transfer, confirm): injected properties, stripped required fields, and tampered values are rejected, never repaired, never rendered. Semantic pin by id matching (byte for byte canonical confirm) is on the roadmap. · How the runtime verifier works →