Approval Decision Integrity Automation: A Record That Could Say Anyone Approved
A record proving who approved something needs the identity to come from the platform, not the request
An approval-decision record exists to answer, later, with confidence: who, specifically, approved this, and when? That answer is only as trustworthy as the weakest point where the identity attached to it could have been supplied by something other than the platform's own verified knowledge of who is actually making the request. If the decision-maker field is simply whatever value a write happens to include, the record can only ever say "someone claimed this identity approved it" — a meaningfully weaker, and for a governance control, unacceptable guarantee.
How the underlying problem shows up before you fix it
A record meant to identify WHO took an action stores that identity as a field supplied by the write itself, rather than derived independently from the platform's own verified knowledge of the caller (here, the authenticated session's own identity).
A record created specifically to serve as a durable, after-the-fact account of a decision carries no database-level restriction against its own core fields (the decision itself, who made it, when) being changed after the record already exists.
The absence of an append-only guarantee on a decision record is invisible under ordinary use — every person following the intended approve/reject flow through the application's own interface never triggers or needs the guarantee at all; it matters only the moment someone reaches the table by another path.
A governance or compliance process elsewhere in the product (an audit trail, a postmortem, a dispute) implicitly relies on an approval record as ground truth about who decided what — an unenforced identity field or a mutable record quietly undermines every one of those downstream assumptions.
Two closely related but genuinely distinct integrity questions — "was the recorded identity real" and "can the record be changed later" — can each be individually true or false; a system needs to check both, since closing only one leaves the record only partially trustworthy.
Why writing the identity straight from the request feels adequate until someone else can write it too
Storing whichever decision-maker value a request supplies is the simplest possible implementation, and for as long as every write genuinely originates from the application's own trusted interface, acting on behalf of the correctly authenticated person, that simple approach happens to produce a correct result every time. The gap is that the database itself has no way to distinguish a write that came through that trusted path from one that reached the same table some other way — and a value supplied directly, with no independent verification against the caller's own actual identity, is a value that could in principle say anything at all. The same logic applies to mutability: allowing updates by default is the simplest starting position, and only becomes a liability once a specific class of record — like an approval decision — needs to be treated as a permanent, non-negotiable fact once created.
How Centriu Helix made an approval record prove itself
Centriu Helix's own approval-decision table records every real approve/reject decision made against one of the product's governance gates. The fix adds a single database trigger addressing both the creation-time and the after-the-fact integrity question in one place.
On INSERT, for any caller that is not the application's own privileged service role, the trigger unconditionally overwrites the decision-maker field with the caller's own verified identity — drawn from the authenticated session itself, never from any value the incoming request happens to carry. Whatever identity a write attempts to claim, the record that actually lands always names the real, verified caller.
On UPDATE, for that same class of caller, the trigger inspects specifically whether the decision, the decision-maker, or the decision timestamp is being changed from its already-recorded value — and if so, rejects the write outright with an explicit append-only error, naming the table and the rule. A decision, once made, stays exactly as it was made; correcting a genuine mistake requires a new, separate decision record, not an edit to the old one, preserving a complete and honest history rather than a record that can be quietly rewritten.
The application's own legitimate server-side path — the trusted service-role identity through which the platform's own official approval flow writes — is explicitly recognized and continues to operate without new friction, since it is the identity this exact protection exists to distinguish real writes from.
What is actually built today
Every newly recorded approval decision has its decision-maker field forced to the caller's own verified session identity — never a value the incoming request itself supplies — making a spoofed approval structurally impossible for a non-privileged caller.
The decision, the decision-maker, and the decision timestamp on an existing approval record are permanently unchangeable once created, for any caller other than the platform's own trusted service-role path.
Correcting a mistaken decision requires recording a new, separate decision — the historical record of what was originally decided, by whom, and when, is preserved completely rather than overwritten.
The application's own official approval workflow, which writes through the platform's trusted service-role identity, is unaffected and continues to record decisions exactly as before.
This guard is specific to the identity and mutability of an individual decision record — it is independent of, and does not change, how multiple decisions are later counted toward an approval threshold.
A signature anyone could have written (illustrative framing of the actual confirmed mechanism)
Before the fix, a write reaching the approval-decision table directly could, in principle, name any decision-maker at all — the record would simply store whatever identity the write claimed. After the fix, the identical write still succeeds, but the identity that actually lands is always the real, verified caller, regardless of what the request itself named. And once any decision record exists, no later write — from that same class of caller — can change what it says, who made it, or when.
What changes operationally
Centriu Helix's approval-decision records now have their decision-maker identity forced to the caller's own verified session on creation, and become permanently unchangeable — on the decision, the decision-maker, and the timestamp — once recorded, closing a gap where a decision could in principle have been attributed to the wrong person or silently altered after the fact.
When this is not the right fit
This automation covers specifically the INTEGRITY of an individual approval-decision record — whether its identity can be trusted and whether it can be changed later. It is a distinct mechanism from this pillar's separate wave 92 page on Helix's approval-GATE, which concerns how MULTIPLE existing, already-trustworthy decisions are counted toward a required threshold — a genuinely different question, answered by a genuinely different mechanism, in a different service.
Trusting a supplied identity vs. deriving it independently, and mutable vs. append-only records
Storing an identity value exactly as a request supplies it, and allowing ordinary updates by default, are both the simplest possible starting points — and both are entirely adequate for records where nothing of consequence depends on the identity being independently verified or the record being permanently fixed. An approval decision is specifically the kind of record where both of those properties matter: the entire value of keeping the record is being able to trust, later, exactly who decided what and when. Deriving the identity from the platform's own verified session rather than the request, and making the decision's own core fields permanently unchangeable once recorded, is the only version of the two that actually delivers that trust rather than merely appearing to.
Related systems
Main system: Centriu Helix.
What it does NOT do
- Does not change how multiple approval decisions are counted toward a gate's required threshold — that is a separate mechanism, covered on this pillar's own wave 92 approval-gate page.
- Does not prevent a genuinely authorized person from recording a NEW decision correcting an earlier mistake — it prevents the EXISTING record of the earlier decision from being edited or deleted, preserving a complete history instead.
- Does not affect the application's own official approval workflow, which writes through the platform's trusted service-role identity and is explicitly recognized as exempt from this specific guard.
- Does not add any new approval workflow, gate type, or governance table — the fix hardens the integrity of Centriu Helix's existing approval-decision records specifically.
- Does not extend this exact append-only-plus-forced-identity pattern to any other record type in Centriu's other systems — this fix is specific to Helix's own approval-decision table, confirmed to have carried this exact gap.
Security and governance
Centriu Helix's approval-decision records now force the recorded decision-maker to the caller's own verified session identity on creation, and make the decision, the decision-maker, and the decision timestamp permanently unchangeable once recorded — closing a gap where a decision could in principle have been attributed to the wrong person or silently altered afterward. Full detail on this module's audit-trail and governance practices lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Could this defect have let someone approve something without any record at all?
No — the gap concerned the TRUSTWORTHINESS of who a record said approved something, and whether that record could later be changed. It did not concern whether a decision got recorded in the first place.
What happens if a genuinely authorized person needs to reverse an earlier decision?
They record a new, separate decision — the fix makes the ORIGINAL record permanently unchangeable, but does not stop the workflow from accepting a later, distinct decision reversing an earlier one, preserving both in the history.
Is this the same finding as the approval-gate page on this site?
No — that page (wave 92) concerns how multiple already-trustworthy decisions get COUNTED toward a threshold. This page concerns whether an individual decision's own identity and content can be trusted and left unchanged in the first place. Different mechanisms, different services.
Does the platform's own automated approval workflow still work the same way?
Yes — it writes through the platform's own trusted, privileged service-role identity, which this guard explicitly recognizes and lets pass through without new friction.
Why force the decision-maker field rather than simply validating it and rejecting a mismatch?
Forcing the value to the caller's own verified identity closes the gap unconditionally, for every caller, with no dependency on the request happening to supply a correct value in the first place — there is no code path left where an incorrect identity could ever reach the stored record.
What does Centriu Helix cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Helix makes an approval record prove itself
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.