Execution governance · Developed in South Africa

Permission to act.
A reason to proceed.

Your systems can act at machine speed. Castle OS checks whether a consequential action should proceed—against configured authority, evidence and policy, before execution.

Explore a decision ↗Discuss your use case →

Demonstration-stage technology. Enforcement requires an integrated execution path.

Independent policy evaluationHuman, API, workflow or agent-initiated actionsDesigned to complement your existing systems
01 / The missing question

Access is only
the beginning.

A valid credential answers who can enter. The next question is whether this particular action is permitted, under these conditions, right now.

01 — AUTHORITY

May this actor do this?

Evaluate the supplied role, delegation and transaction value against a configured authority rule.

02 — CONTEXT

Do the conditions hold?

Check relevant facts and required evidence. A document being present is not the same as a control being satisfied.

03 — DECISION

What should happen next?

Return a policy decision before the selected integrated action commits, with a reason that can be reviewed.

02 / Explore the boundary

Change the facts.
See the decision.

Try three simplified scenarios. These browser simulations illustrate the concept; they do not call the Castle OS engine or move money.

CASTLE OS / DECISION EXPLORERILLUSTRATIVE DATA
Proposed action

Release a supplier payment

The actor has access to payments. Their configured approval limit is R100,000. Access alone does not authorise every amount.

R150,000
Illustrative delegation limit: R100,000
Illustrative policy decision
BLOCK

rule
mode
path action
downstream outcome not observed in this simulation
A PASS is a policy decision, not proof of execution. Review routing and blocking behaviour depend on the implemented integration.
03 / Where it matters

Different systems.
Consequential decisions.

Start with one action and a control that matters. Establish the data, policy and integration needed to evaluate it.

[ ↗ ]

AI & automated actions

Permission to use a tool should not become unlimited permission to act.

  • Agent-initiated payment requests
  • Approved action scope
  • Evidence before a write action
Explore an agent use case ↗
[ ≡ ]

Procurement & payments

Make the transaction-specific question visible before resources are committed.

  • Delegation-of-authority checks
  • Supplier banking changes
  • Duplicate-payment indicators
Scope a transaction control ↗
[ ◎ ]

Audit & forensic review

Move from recurring findings to a focused examination of the underlying control.

  • Historical transaction evaluation
  • Evidence and data-quality gaps
  • Exceptions for practitioner review
Discuss a historical diagnostic ↗
04 / A measured path forward

Understand first.
Enforce deliberately.

Begin with a bounded diagnostic. Progression to live observation and enforcement is a separate engineering and approval decision.

START HERE

01. Historic Shadow

Evaluate an agreed historical sample against selected controls. Surface exceptions and identify what cannot be verified.

Agree the dataset, data dictionary, policy versions and evidence requirements. A 90-day sample can be a starting scope.
INTEGRATION REQUIRED

02. Live Shadow

Observe selected live requests and record how configured rules would respond, without applying their blocking effect.

Validate mappings, rule behaviour and operational impact with the people accountable for the process.
APPROVAL REQUIRED

03. Active Enforcement

Apply approved policy decisions on the integrated execution path before selected actions reach the receiving system.

Define failure behaviour, authorised exceptions, operating ownership and rollback before activation.
05 / Know what the record proves

Approved.
Executed.
Evidenced.

Three different questions. A governance decision explains whether an action was permitted under the evaluated policy. Establishing what happened next requires outcome evidence.

The demonstrated core is ReasonGate and the integrated decision boundary. Broader control-plane and outcome-linking capabilities remain a roadmap, subject to development and validation.
01

The decision record

Submitted facts, effective policy and rule version, evaluation mode, decision and reason. The record is bounded by the information available at evaluation time.

02

Commit Adapter PLANNED

Link evidence from receiving systems to distinguish permission from a confirmed downstream outcome.

03

Causation Record PLANNED

Connect instruction, authority, decision and recorded outcome, while keeping evidence gaps visible.

04

Control Plane PLANNED

Manage policy lifecycle, approvals, deployment states and exception workflows around the decision engine.

06 / Clear boundaries

Good questions.
Direct answers.

Trust starts with understanding what a control can—and cannot—establish.

Does Castle OS replace our ERP or identity platform?

No. Your existing systems retain their roles. Castle OS is designed to add an independent policy decision for selected integrated actions. Compatibility and enforcement coverage must be established for each deployment.

Is this a production municipal deployment?

The experience shown here is a demonstration-stage solution, not evidence of a live municipal deployment. A scoped diagnostic or pilot establishes feasibility with realistic data and practitioner review.

What happens if an action bypasses Castle OS?

Only requests routed through the governed boundary can be evaluated there. Preventing bypass requires integration and access controls on alternative paths. This website does not claim universal visibility or enforcement.

Can we start with sample data?

Yes. Start by agreeing a bounded example and its data requirements. Use synthetic or appropriately authorised sample data first. Confirm security, access, retention and commercial terms before transferring real records.

Does an exception prove fraud or a financial loss?

No. An exception identifies a condition for investigation. Source accuracy, context and professional review matter. A flagged amount is not automatically a loss or a recoverable saving.

How does a diagnostic lead to remediation?

The proposed output is a set of evidence-linked exceptions, data gaps and prioritised control recommendations. Process owners decide corrective action. Implementing changes or active enforcement requires its own agreed scope.

For architects, engineers & assurance teams

Look beyond
the interface.

Follow a request from submitted data to a policy decision. Inspect the boundary, the evidence and the engineering work still required.

Architecture & technical evidence

Understand what sits behind the decision.

Decision facts · ReasonGate · Evidence limits · Capability status

Explore the architecture ↗
Start with one consequential action

Make the next
decision count.

Bring a use case. We’ll discuss the control, the available evidence and a practical first step.

info@castlegroupos.com ↗
Suggested first conversation

One transaction type, one agreed control and the evidence available to evaluate it.

Request a discussion ↗

Opens your email application with a prepared enquiry. No data is uploaded or submitted through this page.