Governance Tiers | Corevexa Demo — Tier Rules, Gates, and Authority Routing

Home Demo How It Works Governance Tiers Panels Deployment Status Contact Docs Core Site

Governance Tiers

Tiering is the control primitive that converts a risk score into enforceable governance: who must approve, whether execution is locked, and what evidence is logged.

This page is the demo’s “tier contract.” The same structure maps to production policy libraries and authority models.

Run the Simulation Tier Matrix Thresholds Examples

Governance rule: higher-tier actions do not execute without valid approval. If governance is unavailable, the gate fails closed in production.

Tier Matrix (What Each Tier Does)

Use this as the evaluation checklist: if the system returns Tier 3 or Tier 4, you should see a lock, a queue item, and a ledger trail.

Tier	Risk posture	Authority required	Execution gate	Routing behavior	Ledger evidence required
Tier 1	Low	Auto	Cleared	Allow	Intake + Eval + Execution status
Tier 2	Moderate	Manager	Locked until approved	Queue for approval	Intake + Eval + Routing + Approval + Execution status
Tier 3	High	Senior	Locked until approved	Escalate; may require additional review	Full lifecycle + escalation events + rationale
Tier 4	Critical	Executive (often multi-approval)	Blocked by default	Block + route to executive queue	Full lifecycle + explicit executive authorization + proof of non-bypassability

Passing criteria: Tier 2–4 must generate a queue item and prevent execution until approval is recorded.

Thresholds (Score → Tier)

The demo uses deterministic thresholds to convert risk score (0–100) into tiers. In production, these thresholds are policy-versioned and environment-specific.

Demo thresholds

Tier 1: 0–39
Tier 2: 40–64
Tier 3: 65–84
Tier 4: 85–100

These thresholds align with the demo console logic.

Signal categories (typical)

Financial exposure: budget, commitment, downside
Data sensitivity: internal → sensitive → regulated
External exposure: limited → broad/public
Reversibility: rollbackability and blast radius

In production, additional signals can be used (jurisdiction, vendor, environment).

Production rule: policy thresholds are versioned, auditable, and recorded per decision (policy_version).

Authority Routing (Tier → Approver)

Tiers drive who must approve. This is a simplified demo mapping that mirrors a delegation-of-authority posture.

Tier 1

Auto-clear (logged)

authority_required: auto

Tier 2

Manager approval required

authority_required: manager

Tier 3

Senior approval; escalation rules apply

authority_required: senior

Tier 4

Executive authorization (often multi-control)

authority_required: executive

Escalation rules (typical)

Tier 3 may require additional review flags before approval.
Tier 4 may require multiple approvals (two-person rule).
Overrides are allowed only with explicit logging and rationale.

Demo simulates the queue state; production enforces role-based controls.

Non-bypassability requirements

Clients cannot mark their own actions “approved.”
Execution must require a valid clearance token.
Token must bind to action_id + request_hash (prevents replay).
Governance service down → execution disabled (fail-closed).

This is what makes governance infrastructure, not policy theater.

Examples (What Should Tier Where)

These examples give evaluators a predictable way to validate scoring, routing, gates, and ledger evidence.

Tier 1 example

Low-impact internal automation tweak with no sensitive data and high reversibility.

Expectation: cleared + ledger events + simulated execution.

Tier 2 example

Moderate budget update or external message to a limited audience.

Expectation: locked + queued + approval event required.

Tier 3 example

Sensitive data export or high-exposure operational change with partial reversibility.

Expectation: locked + escalated routing + senior approval.

Tier 4 example

Regulated data + broad exposure + irreversible change (or high financial exposure).

Expectation: blocked by default + executive authorization required.

Audit evidence check

Pick a decision_id and confirm you can reconstruct the lifecycle from ledger events.

Expectation: intake → eval → routing → approval → execution status.

Bypass test

Try to “execute” a locked action without approval.

Expectation: impossible; must remain locked until approved.

Run These Tests in the Demo How It Works Panels Back to Top

If you want the formal spec version of this: align the tier contract with docs.corevexa.com governance standard and authority model pages.

Guided Evaluation Session

If you want a structured evaluation with pass/fail criteria (what to test, what “passing” looks like, and what the evidence should show):

james@corevexa.com

Request Walkthrough System Status Open Docs Back to Top

Single point of contact is intentional: it preserves routing clarity and governance accountability while Corevexa scales.