Skip to content
Centriu
Centriu TrustOps

AI Policy Decision and Conflict Resolution Automation: When Two Policies Disagree, the Answer Is Never a Coin Toss

Two governance policies that both apply to the same AI action and disagree about the outcome is not a rare edge case — it is the normal state of any organization with more than one team writing rules. Centriu TrustOps resolves that disagreement through a fixed, seven-step precedence order — starting with a platform-wide mandatory floor no team's policy can weaken, then explicit denial over permission, mandatory over optional, specific over generic, configured priority, the most restrictive outcome, and finally a stable tiebreak — so the same inputs always produce the same decision, and the decision names exactly which principle settled it. The same production engine can be run in simulation, including retroactively against real historical events, without ever writing to the actual decision log — because an audit trail that can be rewritten is not an audit trail.
7-step precedence, always named
Simulated without touching the log
Person working on a laptop with notifications on screen
Seven steps decide. Never whichever rule was checked first.

Why "just write a policy" stops working the moment a second policy exists

A single governance policy is easy to reason about: it says what it says, and it applies. The moment a second policy exists — a department's own rule alongside a platform-wide one, a project-specific exception alongside a general standard — the question stops being "what does the policy say" and becomes "which policy wins, and why." Answering that inconsistently, or worse, letting whichever policy happens to be checked first win by accident, is how a platform-wide safety floor quietly gets overridden by a team that wrote a more specific-sounding rule with no idea it was competing with anything.

How the underlying problem shows up before you fix it

A department writes its own AI policy that is technically more specific than a platform-wide rule, and that specificity accidentally weakens a security floor nobody meant to touch.

Two policies fire on the same action with conflicting effects and whichever gets evaluated first wins, with no consistent reason and no record of why.

A proposed policy change gets published and only then does anyone discover, from real user complaints, what it would have blocked.

Reconstructing why a specific action was allowed or denied months ago requires guessing, because the decision trail does not name the policy or the principle that actually decided it.

A generative AI system is asked to "just decide" a governance question and its answer varies slightly between runs, which is exactly the wrong property for something meant to be audited.

Testing what a new policy would do requires either publishing it live or building a separate, hand-maintained test harness that can quietly drift from what production actually does.

Why policy conflicts usually get resolved by accident rather than by design

Most systems evaluate rules by checking them in whatever order they happen to be stored or fetched, which works fine until two rules genuinely disagree — at which point the "decision" is really just an artifact of storage order, not a real judgment about which rule should matter more. Making that judgment explicit requires deciding, in advance, an actual hierarchy of what wins over what — mandatory versus optional, specific versus general, a platform floor versus a local exception — and that hierarchy has to be encoded as a fixed rule, not left to whichever engineer happened to write the query.

How Centriu TrustOps decides and resolves policy conflicts

The evaluation engine is a pure function: given the same input, the same context and the same policy versions, it always produces the same result, because it reads no external clock, touches no database, makes no network call, and does not depend on generative AI at any point in the decision itself — generative AI may explain a decision after it has been made, but the engine's own design statement is explicit that it "should not be the final authority." A decision resolves into one of twelve real outcomes, from a plain allow through allowed-with-restrictions, allowed-with-masking, requiring one or multiple approvals, requiring additional information, blocked, prohibited, suspended by risk, or escalated to an incident or a review — never a bare yes or no. When more than one policy applies to the same action, precedence is resolved through a fixed seven-step order: first, a platform-wide control explicitly marked as a mandatory minimum always wins, specifically so no organization's "more specific" local policy can weaken a security floor that was never meant to be adjustable; second, an explicit denial beats a permission; third, a mandatory policy beats an optional one; fourth, a more specific scope beats a more generic one; fifth, a policy's own configured priority number applies; sixth, if policies still tie, the more restrictive outcome wins; and seventh, a stable identifier comparison breaks any remaining tie, guaranteeing the same result every time regardless of the order records happen to be returned in. Every resolved conflict names, explicitly, which of these seven steps actually decided it — never left as an unexplained outcome. The identical engine also powers simulation: testing a candidate policy runs through the exact same evaluation logic used in production, not a separate test copy that could quietly diverge over time, and a retroactive simulation can be run against real historical events to answer "what would this policy have done" without ever overwriting the original decisions those events actually produced — the simulated result is written to its own separate record, because an audit trail that can be rewritten after the fact is not an audit trail at all.

What is actually built today

A pure, deterministic evaluation engine — no clock, database or network access inside the decision logic, and no generative AI making the call, only explaining it afterward if asked.

Twelve real decision outcomes, from a plain allow through masking, single or multiple approval requirements, additional-information requests, blocking, prohibition, risk-based suspension, and escalation to an incident or a review.

A fixed, seven-step conflict-resolution order: mandatory platform floor first, then explicit denial over permission, mandatory over optional, specific over generic, configured priority, most-restrictive-wins, and a stable tiebreak — applied identically every time.

Every resolved conflict names the specific principle that decided it, rather than presenting an unexplained final outcome.

A mandatory-minimum-control flag that a more specific, locally-scoped policy can never override, closing off the obvious way local specificity could otherwise weaken a platform-wide security floor.

A policy simulator that runs the identical production evaluation engine, not a separate test copy, so a simulated result is never at risk of quietly diverging from what production would actually do.

Retroactive simulation against real historical events, writing its result to its own separate record and never modifying the original decision log.

An explicit, conservative translation function connecting this general-purpose policy engine's twelve outcomes to the narrower five-outcome vocabulary the AI request gateway itself uses, rather than relying on the two systems' terms coincidentally lining up.

A department policy meets a platform floor (illustrative scenario, not a real client)

A department writes its own policy allowing a specific AI action under certain conditions, scoped narrowly to that department's own project — more specific, on its face, than the general organization-wide rule. Separately, a platform-wide policy marked as a mandatory minimum control prohibits that same action outright for a category of sensitive data, regardless of scope.

When an action matching both policies is evaluated, specificity does not win here — the platform floor is checked first, precisely because it is flagged as a mandatory minimum, and it prevails regardless of how narrowly the department's policy was scoped. The decision record names exactly which of the seven precedence principles resolved it: the mandatory-floor rule, not the specificity rule that would otherwise have applied.

Before rolling out a proposed change to the department's own policy the following month, the team runs it through simulation against the last quarter's real request history. The retroactive run shows exactly which past actions would have been treated differently, without altering a single original decision record — giving the team real evidence of the policy's effect before anyone is actually governed by it.

What changes operationally

The structural change is that a policy conflict stops being resolved by accident — by whichever rule happened to be checked first — and becomes a documented, repeatable outcome that names the exact principle that decided it. A platform-wide security floor cannot be quietly weakened by a locally-scoped policy that merely looks more specific. And a policy change can be tested against real historical traffic before it ever governs a real action, with the test using the exact logic that will actually run in production. Centriu attaches no figure to what this prevents; it depends entirely on how many overlapping policies an organization's AI governance program maintains.

When this is not the right fit

An organization operating under a single, simple AI usage policy with no departmental exceptions and no platform-versus-local distinction has nothing to reconcile — conflict resolution exists specifically for the moment more than one policy can apply to the same action, and with only one policy in force that moment never arises.

Whichever rule is checked first vs. a named, ordered resolution

Most systems resolve overlapping rules by accident of evaluation order, which works until two rules genuinely disagree and the resulting decision cannot be explained as anything more principled than "that's the one that got checked first." Centriu TrustOps replaces that accident with a fixed, seven-step order designed around an explicit hierarchy — starting with a floor local policy can never weaken — and names, on every conflict, exactly which step in that order made the call.

Related systems

Main system: Centriu TrustOps.

What it does NOT do

  • Does not let generative AI make a policy decision — the evaluation engine is a pure, deterministic function; AI may explain a decision after the fact but is explicitly, by design, never the final authority.
  • Does not allow a locally-scoped or more specific policy to weaken a platform-wide control flagged as a mandatory minimum — that floor is checked before specificity is ever considered.
  • Does not let a simulation affect a real decision or overwrite a real audit record — both live and retroactive simulations write to their own separate records and never modify an original decision.
  • Does not promise regulatory compliance — this is a governance decision and conflict-resolution mechanism, not a compliance certification.
  • Does not use a separate, hand-maintained test engine for simulation — the same production evaluation logic runs in both contexts, specifically to prevent the two from silently diverging over time.

Security and governance

Every organization using Centriu TrustOps sees only its own policies, decisions and simulation records. The evaluation engine is a pure function with no external dependency inside the decision logic itself, making every outcome reproducible and auditable. Personal data follows Brazil's LGPD (Law No. 13,709/2018). Full detail on access control and audit trails 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

Does AI decide the outcome of a policy evaluation?

No — the evaluation engine is a pure, deterministic function with no AI in the decision path. Generative AI can explain a decision afterward but is explicitly never the final authority.

What happens when two policies apply to the same action and disagree?

A fixed seven-step precedence order resolves it — starting with a mandatory platform-wide floor, then explicit denial, then mandatory-over-optional, specificity, configured priority, the most restrictive outcome, and a stable tiebreak — and the decision names which step resolved it.

Can a department's own, more specific policy override a platform-wide security floor?

No — a policy flagged as a mandatory minimum control is checked before specificity is considered at all, specifically to prevent that.

Does simulating a policy affect real decisions?

No — both live and retroactive simulation write to their own separate records using the identical production engine; the original decision log is never modified.

Can a policy be tested against real past events before it goes live?

Yes — retroactive simulation runs a candidate policy against real historical events and shows what it would have done, without altering any original decision.

How many possible decision outcomes exist?

Twelve, from a plain allow through masking, one or multiple approval requirements, additional-information requests, blocking, prohibition, risk-based suspension, and escalation to an incident or review.

What does Centriu TrustOps cost?

It is sold by subscription with a published starting price — exact current values are on the central pricing page.

See how Centriu TrustOps resolves policy conflicts

Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.

Sources

  1. Centriu TrustOps — public product page — Centriu, 2026-07-20 · link(primária)
  2. Centriu TrustOps — public factsheet (API, JSON) — Centriu, 2026-07-21 · link
  3. Law No. 13,709/2018 — Brazil’s General Data Protection Law (LGPD) — Presidência da República (Brazil), 2018-08-14 · link

Last material update on .

By · AI-assisted production, with human review