Payload-Derived Informed Consent Automation: The Approval Card Can't Hide a Field Anymore

An approval step only means something if what the person reads on the card is actually what is about to happen — a card that summarizes an action in its own words, separately from the real request being built, can drift from that request the moment someone adds a new field to the operation and forgets to also update the card's hand-written description. The person still clicks "Approve," still believes they know what they authorized, and the gap between the two only surfaces later, if it surfaces at all.

A card written by a person, once, at the time an action type is built, is describing that action's CURRENT shape — the moment a field gets added to what the action actually sends, the hand-written card is describing a stale version of it unless someone remembers to update two places in lockstep. A generic fallback that just takes "the first N fields" is worse in a specific way: it looks complete (a normal-looking card, no error, no warning) while silently hiding whatever came after the cutoff, which is exactly the condition under which someone approves more than they realized.

The fix is documented directly in the code's own comment as correcting a named, confirmed defect: the approval card used to be assembled by hand per action, and a generic summary path cut off at 6 fields with `.slice(0, 6)` and no indication that anything was cut. In practice this meant a Maestro campaign update showed its name, budget and bid amount but not `bidStrategy` — which still went into the real request and changed the campaign's actual bidding strategy; a support-ticket email reply didn't show its `subject`; two report-generation actions didn't show their `title`; a client notification showed only a client ID or a user ID, never both, when either could be the real recipient; and any generic table write with 7 or more fields would show the first 6 and execute the rest without anyone seeing them.

The correction does not mean writing a better hand list — it means deriving the card's lines from the payload that is actually about to be sent. `linhasDeConsentimento()` walks every key of the real, already-built request: a nested object opens into one line per inner field specifically because, in the code's own words, that is where a hidden change can bury itself inside what looks like a single innocuous field. A value that is too long to show in full is shortened — but the shortening always announces exactly how much was cut, never silently. The hand-written header a developer writes for an action ("Sends a REAL email to the client") still appears at the top, because it explains what an operation MEANS — it just no longer substitutes for the complete list.

A companion function, `chavesNaoExibidas()`, exists specifically to be called by a test: given the real payload and the rendered card lines, it returns every key that failed to appear anywhere in what the person would see. That is the enforced invariant — not a comment reminding a future developer to keep the card current, but a check a test suite actually runs. And when an action arrives under a capability ID the registry doesn't recognize, the system does not default to treating it as low-risk because nothing is known about it yet — it is deliberately classified as the MOST dangerous class, high-impact-write, requiring approval, with an explicit note that an unknown capability can never become "low risk by omission."

Behind that card sits a real, blocking approval gate. The tool handler that wants to send an email, write to a table, or run a registered action calls a `request()` function and is genuinely suspended — not merely told an approval is pending — inside a Promise that only resolves when a person clicks Approve or Reject on the rendered card, confirmed wired into a real hook that subscribes to pending requests and resolves them from actual UI interaction. A 120-second timeout with no response resolves to REJECTED, not approved — fail-closed, not fail-open — and if no screen is even mounted to display a card (the panel closed, for instance), the request is rejected immediately rather than left hanging indefinitely. Any requests still pending when that hook itself unmounts are also explicitly rejected, so nothing is left in limbo.

Someone asks Sofia to update a Maestro campaign's daily budget and switch its bid strategy at the same time. Under the earlier hand-written card, only the budget and bid amount would have appeared — the strategy change would have gone through unseen. Under the payload-derived card, `bidStrategy` appears as its own line because it is a real key in the request about to be sent, and approving the card means approving exactly that change, not a partial description of it.

Approving an action in Axiom now means approving what is actually about to happen, field by field, rather than a hand-written summary that can quietly fall behind the real request. A newly added field to any action is visible on the card automatically, because the card is generated from the same payload the action sends — nobody has to remember to update a second, separate description. And because the gate itself fails closed on both a timeout and a missing screen, an action can never execute simply because nobody happened to be looking.

This page describes the approval mechanism confirmed wired into Axiom's voice assistant (Sofia) specifically — it was not re-verified this wave as also gating Axiom's separate text-based drafting copilot, the subject of Axiom's existing AI copilot governance page. A team expecting a fully custom, per-action narrative summary instead of a field-by-field payload listing will find the opposite by design: the header explains what an action means, but the full list of fields is never suppressed in favor of prose.

A hand-written approval summary is a description of an action written once, and every field added to that action afterward needs someone to remember to update it too — a class of defect that only ever grows quieter over time, since a card that LOOKS complete gives no sign that it isn't. Centriu Axiom instead treats the real, already-built outbound payload as the single source of truth for what a person is shown: the card is a rendering of that payload, not a separate narrative about it, and a test specifically checks that no field from the real request can go missing from the card.