Policy-as-Code for
Autonomous Systems

The Policy Engine translates regulations, internal controls, and operational procedures into deterministic, versioned, testable code that the Governor executes at every decision point.

Compliance requirements exist in natural language. Autonomous agents execute in code. The Policy Engine is the translation layer—converting human-readable policy into machine-enforceable rules, eliminating ambiguity at enforcement time.

The Translation Challenge

From Natural Language to Executable Code

Every compliance requirement starts as text. Every enforcement decision must be code. The gap between them is where regulated AI deployments fail.

Natural Language
"Procurement orders exceeding ₹2,00,000 require a minimum of three competitive quotations, conflict-of-interest disclosure from all evaluators, budget verification from finance, and dual approval from the department head and financial authority — unless emergency procurement provisions apply under GFR Rule 154."
Policy-as-Code
def evaluate_procurement(action, context): """GFR 2017 Rule 154 — competitive procurement policy""" if action.amount > 250000: require(competitive_bidding(min_vendors=3)) require(conflict_check(evaluators=context.evaluators)) require(budget_verified(finance_approval=True)) require(dual_approval(['dept_head', 'cfo'])) if emergency_provision_7_3_b(context): return APPROVE_WITH_AUDIT if not all_requirements_met(): return BLOCK return APPROVE
Why Prompts Are Not Policy

Three Approaches Compared

Approach
Strengths
Limitations
Compliance Suitability
Prompt Engineering
Easy to implement, no special tooling
Non-deterministic outputs, model drift, injection risks, limited auditability
Generally insufficient as primary control
Semantic Guardrails
ML-based detection, confidence scoring
Probabilistic ("92% confident"), false positives/negatives, weak traceability
Useful as detection layer, not sole evidence
Policy-as-Code
Deterministic, testable, version-controlled, auditable
Requires translation effort, engineering overhead
Appropriate for defensible controls and audit evidence

Practical deployment: Many organizations combine approaches — policy-as-code for enforcement; semantic guardrails as complementary detection and monitoring layers during calibration.

What Policy-as-Code Means

Four Core Principles

Policy Engine treats compliance like infrastructure-as-code: versioned, testable, deployable, and rollback-ready. Policies are the code that runs your governance — not PDFs documenting aspirational controls.

01

Code, Not Text

Policies are expressed as executable logic — Policy DSL, Python, or Rego — not stored as ambiguous prose. Natural language invites interpretation; code produces a single, inspectable outcome.

# Natural language: "oversight for high-risk transactions" if risk_score > 7.5: require(human_approval(role='Risk_Manager'))
02

Version Controlled

Every policy change is a commit. Full history of who changed what, why, and when — with ability to revert immediately if an update causes unintended enforcement patterns.

$ git log --oneline policies/financial_controls.py a3f7c2e Update dual approval threshold to $300K b8d4f1a Add emergency procurement exception (CFO memo) c2e9a7b Initial financial controls policy
03

Test-Driven Compliance

Every rule has unit and regression tests built from historical cases, edge scenarios, and compliance team examples. Tests demonstrate policy behavior across scenarios and catch regressions before deployment.

def test_below_threshold_auto_approves(): action = ContractAward(value=200000, rationale=None) assert policy.evaluate(action).result == APPROVE def test_no_rationale_blocks(): action = ContractAward(value=300000, rationale=None) assert policy.evaluate(action).result == BLOCK
04

Continuously Deployed

Policy changes follow a release lifecycle: develop → test → stage → promote. When regulations update, policy teams implement, validate, and roll out changes in defined timeframes rather than ad-hoc manual updates.

Regulation Published
Code Updated
Tests Validated
Staged Rollout
Production
Translation Process

How Translation Works

The translation process combines governance engineering with legal interpretation. We partner with your compliance and legal teams so codified policy reflects regulatory intent and organizational reality.

Stage 1
1–2 weeks

Requirement Extraction

Governance engineers and legal counsel review source material — regulations, policies, SOPs. Extract enforceable requirements: thresholds, approval matrices, prohibited actions, mandatory checks, timing constraints.

Deliverable Requirements matrix mapping each rule to source regulation (citation + section) and enforcement condition.
SourceGFR 2017 Rule 173 / CVC Guidelines
ConditionContract value > $250K
RequirementDocument contract type rationale before award
TimingPre-award
Stage 2
~1 week

Logic Design

Translate requirements into decision logic: conditions, thresholds, dependencies, exception paths. Produce flowcharts and pseudocode for compliance review and sign-off before implementation.

IF action = award_contract AND contract_value > $250,000 AND contract_type_rationale = null THEN BLOCK → "GFR 2017 Rule 173 / CVC Guidelines requires documented rationale" ELSE IF rationale.length < 50 THEN ESCALATE → contracting_officer_review
Stage 3
1–2 weeks

Code Implementation

Governance engineers implement production policy code. Each rule includes inline citation linking back to source regulation for auditability. Code stored in Git with full change history.

class GeneralFinancialRulesPolicy: THRESHOLD = 250000 # GFR Rule 9(iv) — ₹2,00,000 def evaluate_contract_award(self, action, context): """GFR 2017 Rule 173 / CVC Guidelines""" if action.contract_value <= self.THRESHOLD: return PolicyDecision(APPROVE, "Below threshold") if not action.contract_type_rationale: return PolicyDecision(BLOCK, "GFR 2017 Rule 173 / CVC Guidelines: Missing rationale")
Stage 4
~1 week

Test Suite Development

Unit and regression tests covering normal cases, edge cases, and exception paths. Tests written with input cases from historical decisions and compliance scenarios. CI pipeline blocks merges below agreed coverage thresholds.

Below threshold → APPROVE
Above threshold, no rationale → BLOCK
Insufficient rationale → ESCALATE
Conflict of interest detected → BLOCK
Target coverage: >90% line coverage, >85% branch coverage
Stage 5
1–2 weeks

Certification & Deployment

Compliance and legal review code, tests, and documentation. Certification packet signed by required stakeholders. Shadow-mode deployment validates before enforcement. Staged rollout with automatic rollback on error spikes.

Legal Regulatory mapping confirmed
Compliance Coverage certified
Audit Test coverage validated
Security Technical review complete
Policy Lifecycle Management

Continuous Compliance

Regulations change. Business processes evolve. Risk thresholds shift. The Policy Engine is designed to keep enforcement continuous, auditable, and maintainable as requirements change.

Phase 1

Policy Development

  • Extract enforceable requirements from regulations, SOPs
  • Design decision logic with compliance and legal teams
  • Write policy code and unit tests
  • Validate in shadow mode (observe-only)
2–6 weeks (first domain)
Phase 2

Certification & Approval

  • Legal confirms regulatory mapping
  • Compliance certifies completeness
  • Internal audit validates test coverage
  • Security reviews technical implications
Gate: No production deployment until required approvers sign off
Phase 3

Staged Deployment

  • Shadow-mode validation (collect "would-have" decisions)
  • Canary rollout (10%) → staged ramp to 100%
  • Monitor decision metrics and escalation volumes
  • Auto-rollback on error spikes or compliance request
Phase 4

Production Operation

  • Policy enforces decisions in real-time
  • Continuous monitoring and alerting
  • Audit records produced for every decision
  • Operator procedures for escalations and overrides
Phase 5

Monitoring & Iteration

  • Review operational telemetry (monthly/quarterly)
  • Identify false positives and false negatives
  • Tune thresholds based on observed outcomes
  • Add regression tests for new edge cases
Phase 6

Regulatory Updates

  • Track regulatory publications and guidance
  • Impact analysis — which modules are affected?
  • Code updates, retest, re-certify, re-deploy
  • Communicate changes to stakeholders and auditors
Critical risk1–2 weeks
Standard updates4–8 weeks
GuidanceNext scheduled review
Policy Library

Accelerate with Certified Templates

Configurable templates for common regulations and industry standards. Intended as executable starting points — must be reviewed and customized to your organization's processes and legal requirements.

Regulatory Compliance
DPDP Act 2023
  • Lawful processing basis (Section 4)
  • Consent obligations & withdrawal (Section 6)
  • Data principal rights automation (Sections 11–13)
  • Automated processing controls (Section 8)
Companies Act 2013 / SEBI LODR
  • Board approval thresholds (SEBI LODR Reg. 24)
  • Internal financial controls & segregation of duties (Sec. 134(5))
  • Books of accounts & audit trail requirements (Sec. 128)
ABDM Health Data Policy
  • Health data access controls (Sec. 3.2)
  • Purpose limitation & minimum necessary (Sec. 4.1)
  • Audit logging for health data access (Sec. 7.3)
Government Procurement
GFR 2017 / CVC Guidelines
  • Competitive bidding & quotation verification (Rule 160)
  • Single tender justification (Rule 161)
  • Contract award rationale (Rule 173)
  • Conflict-of-interest disclosure (CVC guidelines)
Financial Services
PMLA 2002 / RBI KYC
  • Customer identification & verification (PMLA Sec. 12)
  • Suspicious transaction reporting (STR) triggers
  • Politically Exposed Persons (PEP) screening (RBI KYC Master Direction)
PCI DSS
  • Cardholder data access restrictions
  • Transaction monitoring and access controls
Operational Controls
Change Management
  • Change approval workflows and emergency paths
  • Rollback requirements and audit gates
Data Classification
  • Classification tiers, access controls
  • Encryption and retention enforcement
Approval Hierarchies
  • Amount-based approval matrices
  • Multi-signature rules and escalation paths
Each template includes: policy code with inline citations, test suite, configuration guide, compliance documentation, and deployment guide.
Integration with Governor

Code You Certify Is the Code That Runs

Policy Engine compiles policies into Governor-executable format — no manual translation, no drift between intent and enforcement. What your compliance team certifies is exactly what evaluates every agent action.

01

Policy Compilation

DSL/Python/Rego compiled into optimized, versioned package. Compilation includes syntax checks, static analysis, and unit test execution. Output: signed package with version, hash, and test results.

02

Version Registration

Compiled packages registered in central policy registry with full metadata. Registry provides auditable trail: who deployed what and when.

03

Distribution to Governors

Packages distributed securely to all Governor instances. Cloud (HTTPS/mTLS), On-prem (internal registry), or Air-gapped (signed media). Each Governor validates package signature before loading.

04

Hot-Reload & Atomicity

Governor supports atomic policy loading — new policy loaded alongside old, in-flight decisions complete under prior version, new decisions immediately use new version. Instant rollback to previous package supported.

Consistency & Verification Guarantees
Atomic versioning Governor instances run identical policy versions coordinated by registry
Signature verification Governors reject tampered or unsigned packages
Rollback time <60s to revert and enforce previous version
Drift detection Registry monitors Governor versioning and alerts on drift
Regulatory Mapping Examples

From Regulation Text to Enforcement Code

Illustrative templates showing how specific regulations become executable logic. Final deployments require legal and compliance sign-off.

DPDP Act 2023 — Section 4

Personal data may be processed only for a lawful purpose for which the Data Principal has given consent, or for certain legitimate uses under Section 7 (state functions, legal obligation, medical emergency, employment).

Audit value Every data processing action produces a lawful basis record — directly traceable to Article 6(1) text.
def evaluate_data_processing(action, context): """DPDP Act 2023 — Section 4 - Lawful basis for processing""" lawful_bases = [] # (a) Consent if getattr(context, "user_consent", None): consent = context.user_consent if (consent.obtained and consent.specific_to(action.purpose) and consent.free_and_informed()): lawful_bases.append("consent") # (b) Contract necessity if (action.purpose == "contract_performance" and context.contract and context.contract.includes_data_subject(action.subject)): lawful_bases.append("contract") if not lawful_bases: return PolicyDecision(BLOCK, "DPDP Act S.4: No lawful basis for processing") return PolicyDecision(APPROVE, basis=lawful_bases[0])
Companies Act 2013 Sec. 134(5) / SEBI LODR Reg. 24

Financial transactions above threshold require dual approval from independent signatories. No single person can initiate and approve the same transaction — per Companies Act 2013 Sec. 134(5) internal financial controls requirement.

Audit value Every financial approval produces a segregation record — defensible for Companies Act Sec. 134(5) internal controls audit and SEBI LODR compliance review.
def evaluate_financial_transaction(action, context): """Companies Act 2013 Sec. 134(5) / SEBI LODR Reg. 24 — Segregation of duties""" if action.amount <= 50000: return PolicyDecision(APPROVE, "Below threshold") # Dual approval required if len(action.approvals) < 2: return PolicyDecision(ESCALATE, escalate_to="finance_approver", rationale="Companies Act S.134(5): Dual approval required") # Segregation check — initiator cannot approve if action.initiator in [a.approver for a in action.approvals]: return PolicyDecision(BLOCK, "Companies Act S.134(5): Initiator cannot be approver") return PolicyDecision(APPROVE, audit_metadata={"approvers": action.approvals})
GFR 2017 Rule 161 — Single Tender Justification

Single tender procurement requires written justification with specific elements. Approving authority level depends on contract value. Deviations must be reported to CVC for contracts above prescribed limits.

Audit value Justification completeness, approving authority level, and CVC reporting requirements enforced at every award — full GFR Rule 161 audit trail.
def evaluate_single_tender(action, context): """GFR 2017 Rule 161 / CVC Guidelines — Single tender justification""" contract_value = action.contract_value justification = action.justification if not justification: return PolicyDecision(BLOCK, "GFR Rule 161: Written justification required") required_approver = ( "competition_advocate" if contract_value > 750_000 else "contracting_officer" ) if justification.approved_by_role != required_approver: return PolicyDecision(BLOCK, f"GFR Rule 161: Requires {required_approver}") if contract_value > 13_500_000 and not justification.publicly_posted: return PolicyDecision(BLOCK, "CVC guidelines: Single tender >₹25L requires CVC report") return PolicyDecision(APPROVE)
Certification & Auditability

Four Pillars of Audit Evidence

Policy Engine produces artifacts designed to support legal and audit review. These artifacts do not replace legal opinion — they provide the evidence and reproducible trails auditors and counsel need.

Pillar 1

Regulation Mapping Matrix

Spreadsheet mapping every policy rule to source regulation: citation, section, requirement text, implementation approach, test coverage. When auditors ask "How do you ensure DPDP Act compliance?" — you answer with this matrix plus decision records showing enforcement in practice.

ModuleRuleRegulationTests
DPDP Act 2023lawful_basis_requiredArt. 6(1)15 / 100%
Companies Act 2013 / SEBI LODRdual_approval_threshold§40412 / 100%
GFR 2017 / CVC Guidelinessole_source_justification6.30218 / 100%
Pillar 2

Certification Documentation

Certification packet signed by legal, compliance, and audit stakeholders attesting that policy code implements mapped regulatory requirements and tests validate expected behavior.

"I, [Chief Compliance Officer], certify that DPDP Act Compliance Policy v3.2.1 (hash: sha256:a8f3c2e9...) implements DPDP Act 2023 Sections 4, 6, 7, 8, and 11–13 as applicable to the organization's data processing activities. Effective: 2025-01-15."
Pillar 3

Audit Log Integration

Every Governor decision records policy module, version, and hash so specific decisions can be traced to the exact code that evaluated them.

{ "decision_id": "gov_20250115143218", "policy_module": "DPDP_compliance", "policy_version": "3.2.1", "policy_hash": "sha256:a8f3c2e9...", "rules_evaluated": [{ "rule": "lawful_basis_required", "outcome": "PASS", "basis_used": "consent" }], "decision": "APPROVE" }
Pillar 4

Replayability & Forensics

Given any decision record, the system can re-execute the evaluation using the recorded policy version and inputs to demonstrate the outcome is deterministic and reproducible — for disputes, investigations, and regulatory review.

$ axiosky policy replay --decision-id gov_20250115143218 Loading decision... ✓ Retrieving policy v3.2.1 (sha256:a8f3...)... ✓ Re-executing policy... ✓ REPLAY RESULTS: Original Decision: APPROVE Replayed Decision: APPROVE Rationale Match: ✓ Verdict: DETERMINISTIC
Technical Specifications

Design Targets & Performance

Figures represent design targets and observed performance in reference deployments. Production performance varies with topology, hardware, policy complexity, and workload. Load testing required before production sizing.

Policy Compilation
Languages supportedPolicy DSL, Python 3.10+, Rego (OPA)
Compilation speed<5s per module (500–1,000 lines)
Compiled output size200–800 KB per module (typical)
Test execution1,000+ unit tests in <30s (CI)
Policy Distribution
Distribution modelPush (cloud) or pull (on-prem / air-gapped)
Transfer securityTLS 1.3 with mutual authentication
Package signingEd25519 digital signatures
Distribution speed<10s to 100+ Governors (cloud, typical)
Version Management
Storage backendGit or compatible VCS
Versioning schemeSemantic versioning (major.minor.patch)
Rollback time<60s to revert and enforce previous version
Concurrent versionsA/B testing and canary supported
Scale & Capacity
Policy modules1,000+ per deployment
Rules per module10,000+ without observable degradation
Max package sizeUp to 10 MB (compiled)
Governor fleet10,000+ Governors in single deployment
Integration Points
Git platformsGitHub, GitLab, Bitbucket, Azure DevOps
CI/CDJenkins, GitHub Actions, GitLab CI, CircleCI
Artifact storageS3, Azure Blob, GCS, Artifactory, on-prem NFS
SecretsHashiCorp Vault, AWS Secrets Manager, Azure Key Vault
IDEVS Code extension with syntax highlighting & autocomplete
NotificationsSlack, PagerDuty, email, webhooks
Common Questions

STILL HAVE DOUBT?

Axiosky

The Standard for
AI Governance.