Your policy. Applied correctly.

You are responsible for AI decisions in production. ARCS helps ensure policy is defined clearly, applied correctly and kept aligned as systems evolve.

Your policy may look fine on paper. But is it implemented correctly, kept up to date, and visible to the people responsible for AI outcomes?

A policy applied incorrectly is a policy not truly applied.

Policy may come from laws, company policy, business rules and more. It is then translated into prompts, tools, workflows and code. Once that happens, governance cannot clearly see whether the policy has been applied correctly in the live system.

That creates a gap between what was approved and what the system is actually doing. The gap can grow each time policy changes, because every update has to be translated and applied again.

ARCS helps organisations make sure policy is applied correctly in live AI systems. It gives teams a clearer way to see and manage four things that are often hidden across prompts, tools, workflows and code.

What policy is running
See the active policy in a customised English like language that people can review more easily.
Where policy runs
Control where policy is applied across the live system.
When rules activate
Control when policy should apply in different situations.
How policy is applied
Control how policy is enforced so it is easier to see, review and manage.

What ARCS Currently includes

ARCS is an AI governance software platform that integrates into your current AI system to implement policy in live workflows, using an English like rule format so stakeholders can review policy more easily and help keep it correct and up to date.

Current implementation of ARCS – ARCS version 1 includes the following:

ARCS DSL VS Code extension Rules are written in the ARCS DSL Visual Studio Code extension in a customisable English like format, so policy can be expressed in a form that stakeholders can understand and review more easily.

JSON compiler Rules are compiled into JSON and prepared for runtime use, so what is written in the rule format becomes something the live system can load and apply.

Python based runtime Rules are loaded into a Python based runtime that evaluates policy during live system operation. The same model can be extended to other languages through thin wrappers around the runtime.

Live boundary integration Your application calls ARCS from the point where a policy decision is needed, passing context from the real workflow so the rule is checked against the live situation.

Structured result and next action ARCS returns a result such as allow, block, modify, escalate, alert, terminate or require human review, together with the reason, audit information and the next handler or function to call.

Local policy operations dashboard Rules can be viewed through a React based dashboard running on the local intranet, so policy and governance stakeholders can see what is active, review rules more easily, and inspect how policy is being applied without relying only on developer tooling.

Decision testing and runtime visibility The dashboard can be used to view loaded rules, run policy checks with example or live context, inspect returned results, and review decision evidence so teams can understand how ARCS is behaving in practice.

Get a focused partner for policy implementation Work with a partner focused on improving ARCS tooling over time, so you can benefit from the latest approach for helping keep policy correct and up to date in live AI systems.

Without ARCS. With ARCS

Without ARCS

Policy is handed from governance, legal, risk, or business teams to engineering for implementation

It gets translated into prompts, code, tools, workflow steps, and other controls across the system.

Once spread across the stack, it becomes harder for other stakeholders to see where it is applied, when it activates, and how it is being used.

When policy changes, updates take more engineering effort and it can still be hard to know if the live system is applying it correctly.

With ARCS

Teams work from one clear, reviewable policy layer instead of scattered implementation across the stack.

Policy can be understood by different stakeholders, including people without a technical background.

ARCS gives a structured way to control where policy is applied, when it activates, and how it is enforced.

That makes policy easier to change, easier to verify, and easier for both policy and technical teams to see in production.

ARCS helps ensure approved policy is applied correctly in the live system, where AI decisions are actually made.

Why teams use ARCS instead of building this themselves

You can absolutely build your own guardrail layer. Many teams start that way. The problem is :

• you still need a way to make policy visible and reviewable, so governance and other stakeholders can check that it is correct

• you still need to decide where policy should run across the system, so it is applied at the right points

• you still need to decide when rules should activate, because timing affects what the system actually does

• you still need to decide how policy should be applied through the right execution pattern, including how direct calls are controlled and verified rather than left buried in application logic

Policy more people can understand

ARCS defines policy in one place, in an English like language that policy, governance and technical teams can work with. That makes it easier to review, update and keep aligned with what has been approved.

Choose where policy is checked

ARCS gives you 26 execution boundaries across the AI stack, including model calls, tool calls, retrieval, memory and workflow transitions. Checks can be configured before or after those steps, so policy runs where behaviour actually needs to be controlled.

Choose when a rule should apply

Not every rule should run all the time. ARCS gives you 10 built in ways to decide when a rule applies, for example by user, input, tool, workflow step or risk condition.

Choose how policy is enforced

Different situations need different enforcement methods. ARCS gives you 7 practical ways to enforce policy, from direct checks at the point of action to framework and network level control.

Most teams do not have a dedicated governance technology capability focused on designing and maintaining this properly over time. With ARCS, your team keeps ownership of the policy and enforcement choices while gaining a specialised governance and implementation capability, more configurable options, and a more structured way to keep policy aligned in production.

How ARCS works

ARCS gives teams a dedicated policy layer that sits alongside the live AI system. Different teams can work from the same reviewable policy, instead of leaving rules buried across prompts, code and workflow logic. That gives the organisation a clearer view of how policy is meant to be applied and lets teams add, change or remove policy without altering the underlying application code.

Teams can configure three key parts of enforcement: where policy runs, when a rule applies and how it is enforced. Then, when the system reaches a point where behaviour matters, such as a model call, tool call, retrieval step or workflow transition, ARCS checks what should happen there. It can allow, block, modify, escalate or require review, with clear evidence of what ran, where and why.

Where ARCS matters most

High consequence decisions

Loan approvals, fraud checks, hiring screens and other decisions where policy must be enforced before an outcome is allowed.

AI workflows with tools and data access

Internal copilots, retrieval flows and agentic workflows where prompts, tools and workflow steps can drift out of line with policy.

Regulated production systems

Finance, healthcare, insurance. Enforce policy at the point of execution with clear audit evidence.

How ARCS enforces policy in production

ARCS provides structured runtime enforcement across defined execution points, activation strategies and enforcement patterns.

01.

Policy DSL
for
Governance

Policies written in an English like domain language aligned to organisational vocabulary. Legal obligations and operational policies become explicit rules that can be reviewed by governance, legal and engineering teams.

02.

Enforcement at 26 Execution Boundaries

ARCS evaluates policy before and after key execution points including model calls, tool execution, retrieval, memory operations and workflow transitions.

03.

10 Rule Activation Strategies

Policies activate only when relevant signals appear in context using keyword and phrase detection, pattern matching, classifiers, structured field checks, domain checks, sequence detection, velocity monitoring and other activation strategies.

04.

7 Enforcement Patterns

ARCS integrates through multiple enforcement paths including explicit boundary calls, in process runtime instrumentation, framework interceptors, network proxy enforcement and MCP aware protocol control.