Identify the sources
Agree transaction exports, supplier records, change histories and supporting approvals. Record the source, extraction period and data owner.
← CASTLE OS / OVERVIEWA clear boundary.
Architecture & technical evidence
A clear boundary.
An explainable decision.
Follow the facts, inspect the execution path and understand the limits of the record. Technical depth, without treating a demonstration as a production claim.
01 / From source records to decision facts
Structure the data.
Preserve the uncertainty.
A policy engine needs defined inputs. A diagnostic starts by establishing what the supplied records mean, which fields can be mapped and what is missing.
Define the meaning
Use a data dictionary or validated mapping to establish identifiers, currencies, date formats and business events. Ambiguous meanings require confirmation.
Check usability
Identify missing fields, malformed values and inconsistent references. Keep original records and transformation lineage available for review.
Submit defined facts
Prepare the agreed decision inputs and applicable policy context. Where essential inputs are unavailable, make the limitation explicit.
ILLUSTRATIVE SOURCE ROW
PaymentRef: PAY-0042 Amount: "150 000.00" Currency: ZAR Approver: OFF-017 DelegationRef: DEL-2026-04
ILLUSTRATIVE DECISION FACTS
payment_id: PAY-0042 amount_minor: 15000000 currency: ZAR authority_limit_minor: 10000000 policy_version: demo-v1
The authority limit must come from a validated source applicable at the relevant time. Formatting an amount or matching an identifier does not establish truth, authorisation or legal compliance.
02 / The integrated execution path
The decision sits
before the consequence.
ReasonGate evaluates submitted facts against the effective configured policy. An integrated enforcement point applies the decision before the selected request reaches the receiving system.
Originating systemERP · API · workflow · agent
→Integrated boundaryCastle Proxy / ReasonGate
Configured policy evaluation
→Configured policy evaluation
Receiving systemExecutes the business action
Conceptual placement · deployment-specific routing and configuration
PASS
Policy permits the evaluated request. The receiving system still determines the execution outcome.
BLOCK
An approved blocking condition denies the request on the integrated path.
FLAG_FOR_REVIEW
Raises a review decision. It does not itself prove a request was held; handling must be implemented.
SHADOW
Observation mode records evaluation behaviour without applying the rule’s blocking effect.
Castle OS does not execute the payment or business action. Alternative routes, access permissions, failure behaviour and policy freshness must be addressed in the deployment design.
What must an integration establish?
Trusted input sources; request and policy-version binding; the enforcement point; alternative-path controls; state and concurrency requirements; authorised exceptions; timeout and failure behaviour; evidence delivery and retention; and operational ownership. Cross-channel idempotency and any replay guarantees require explicit implementation and testing.
03 / Inspect the evidence
Know what was decided.
Know what remains unknown.
A decision record explains the evaluation. It must not silently become a claim that the source data was true or the downstream action happened.
What this record can explain
- Which submitted facts were evaluated.
- Which policy and rule versions applied.
- The evaluation mode, decision and reason.
- The decision-time information available to the engine.
What it does not establish alone
- Authenticity or completeness of source evidence.
- Human intent or legal correctness.
- Actions taken outside the integrated boundary.
- Downstream execution, settlement or reversal.
Evidence Chain Lite is an asynchronous recording component. Delivery, retention and failure handling need validation; a boundary decision is not an unconditional guarantee that its record was durably retained.
04 / Capability status
Precision over promises.
This is a scoped product position, not a certification or production acceptance report. Demonstrated behaviour does not establish throughput, availability or full integration coverage.
| Capability | Position | Scope / evidence to examine |
|---|---|---|
| ReasonGate policy evaluation | DEMONSTRATED CORE | Configured-rule evaluation on submitted facts in a controlled demonstration. |
| Delegation check & request denial | DEMONSTRATED PATH | The GOV-011 demonstration returns a BLOCK / HTTP 403 on an integrated test path. This is not a claim of municipal production use. |
| Historical diagnostic | SCOPED VALIDATION | Agree data readiness, control feasibility and practitioner review against a bounded sample. |
| Live Shadow & active deployment | INTEGRATION REQUIRED | Customer-specific mappings, routing, operational tests and authorisation are required. |
| ESCALATE / HOLD | NOT DEMONSTRATED HERE | Identifiers are present in the reviewed code context; end-to-end operational handling is not established by the demonstrated path. |
| Commit Adapter | PLANNED | Link receiving-system evidence to the originating decision and distinguish observed outcomes from missing confirmation. |
| Causation Record / Explorer | PLANNED EXTENSION | Connect instruction, authority, decision and recorded outcome. Preserve evidence gaps rather than infer closure. |
| Control Plane | PLANNED | Policy lifecycle, approval workflows, deployment management and observability require further development and validation. |
05 / A useful technical evaluation
Bring one control.
Test its boundaries.
- Define the proposed action and who is accountable for its policy.
- Supply sample records and confirm the mapping, policy dates and evidence requirements.
- Exercise permitted, denied, missing-data and conflicting-input cases.
- Inspect the decision records and independently check what they support.
- Agree what must be engineered and validated before any live integration.
A useful first pass can use synthetic sample data. No production records need to be uploaded through this website.
Architecture review
Make the technical questions concrete.
Discuss a sample use case, the decision boundary and the evidence needed for a credible evaluation.