Risk Scoring Model

Risk Scoring Model | Corevexa Docs
CVX Corevexa Docs
Home Getting Started Architecture API Roadmap FAQ

Risk Scoring Model
Deterministic Pre-Execution Risk

Risk scoring exists to make governance proportional and enforceable. The model is designed to be deterministic (same inputs → same score) so audits, incident reconstruction, and compliance reviews remain coherent.

Risk Bands Inputs Maps to Authority Examples
Deterministic scoring Proportional controls Default deny for unknowns
Core rule: risk is calculated before execution. If risk cannot be computed safely, the correct outcome is deny/queue.

Why Risk Scoring Exists

Without risk scoring, every action must be treated as equally dangerous or equally safe—both are wrong. Layer-7 uses risk scoring to route authority requirements and enforce gates proportionally.

Governance proportionality

Low-risk actions can be allowed automatically; high-risk actions require approvals and stronger logging guarantees.

Consistency at scale

Multiple teams and vendors can run the same model and produce consistent outcomes across environments.

Audit reconstruction

Risk reasons explain “why” a decision was escalated, denied, or forced through multi-sig.

Risk is not a vibes score. It’s a structural control input used to route authority and determine enforceability.

Risk Bands

The risk model outputs a normalized score in [0.00 – 1.00] and assigns a band. Bands map directly into authority + enforcement behavior.

Band Score range Typical behavior
Low 0.00 – 0.24 Auto-allow if policy passes + ledger confirmed (or ledger async for non-sensitive reads)
Medium 0.25 – 0.54 Allow with stricter policy gates; optional single-signature depending on action class
High 0.55 – 0.84 Requires authority approval (role-based); ledger must confirm before execution
Critical 0.85 – 1.00 Multi-sig + explicit exception path; may require executive panel review; default deny until satisfied
The score is only meaningful if it drives enforceable actions. Band → authority route → enforcement result.

Scoring Inputs

Risk scoring uses structured signals from the decision object. All inputs must be stable and auditable. If an input is missing, the model must fail safe.

Primary inputs

  • Action class (read/write/deploy/transfer/notify/etc.)
  • Environment (dev/staging/production)
  • Target sensitivity (PII, credentials, funds, infrastructure)
  • Blast radius (single object vs multi-system / bulk)
  • Irreversibility (can rollback or not)

Secondary modifiers

  • Actor role (privileged vs unprivileged)
  • Time pressure (emergency flag triggers stricter logging)
  • Novelty (first-time action/target → higher scrutiny)
  • Policy exceptions (requires_exception increases risk)
  • Dependency health (ledger degraded → deny/queue)
Risk must be explainable. Every score includes “reasons” so the audit trail can show the basis for escalation or denial.

Deterministic Scoring (Reference Model)

This is a reference scoring pattern that stays deterministic and easy to audit. Implementations can extend weights, but must keep “reasons” and fail-safe handling.

# Reference scoring (pseudocode) score = 0.0 reasons = [] # 1) Action class base if class in [“read_public”]: score += 0.05; reasons += [“read_public”] if class in [“read_sensitive”]: score += 0.25; reasons += [“read_sensitive”] if class in [“write_data”]: score += 0.35; reasons += [“write_data”] if class in [“deploy_code”]: score += 0.55; reasons += [“deploy_code”] if class in [“transfer_funds”]: score += 0.65; reasons += [“monetary_action”] if class in [“rotate_credentials”]: score += 0.75; reasons += [“credentials_action”] # 2) Environment modifier if env == “production”: score += 0.20; reasons += [“production_environment”] if env == “staging”: score += 0.10; reasons += [“staging_environment”] # 3) Sensitivity modifier if target_sensitivity == “PII”: score += 0.15; reasons += [“pii_target”] if target_sensitivity == “infra”: score += 0.25; reasons += [“infrastructure_target”] # 4) Blast radius / irreversibility if blast_radius == “bulk”: score += 0.20; reasons += [“bulk_scope”] if irreversible == true: score += 0.15; reasons += [“irreversible_change”] # 5) Exception / novelty if policy_requires_exception: score += 0.25; reasons += [“policy_exception_required”] if first_time_target: score += 0.10; reasons += [“novel_target”] # clamp score = min(1.0, max(0.0, score)) band = band_for(score)
Determinism is a governance feature. If risk changes unpredictably, authority routing becomes incoherent.

Risk → Authority → Enforcement Mapping

Risk bands drive required approvals and the enforcement outcome emitted to the gateway. Authority routing is explained in the authority model; this page defines the mapping contract.

Authority routing contract

  • Low: no approvals required (unless policy forces approval)
  • Medium: optional single-approval for write actions
  • High: required role approval(s) by action class
  • Critical: multi-sig + exception path; may require executive review
Authority Model →

Enforcement contract

  • Allow only when policy passes + authority satisfied + ledger confirmed
  • Deny when policy fails, risk unknown, or dependencies degraded
  • Queue while awaiting approvals or ledger recovery
  • Escalate when exception required or critical risk detected
Decision Ledger →
Risk does not “decide.” Risk determines what authority must decide and what gates must be satisfied.

Examples

Example A — Read a public doc

  • Class: read_public
  • Env: production
  • Sensitivity: none
  • Outcome: score ~0.25 → Medium
Policy passes → likely allow with ledger confirmed

Example B — Deploy code to production

  • Class: deploy_code
  • Env: production
  • Blast radius: bulk
  • Outcome: score ~0.95 → Critical
Multi-sig + exception path; default deny until satisfied

Example C — Transfer funds

  • Class: transfer_funds
  • Env: production
  • Irreversible: true
  • Outcome: score ~1.00 → Critical
Finance + security approvals; ledger confirmation required

Example D — Write to a customer record (PII)

  • Class: write_data
  • Target: PII
  • Env: production
  • Outcome: score ~0.85 → Critical
Approval required; may enforce dual-control depending on policy
The examples are intentionally conservative. You can tune thresholds later, but your first deployment should default to strict.
Next: Authority Model Back: Governance Engine API Reference
Corevexa Docs — Layer-7 Governance Infrastructure
© Corevexa Labs