Engine Logic & Transparency

This page describes the current repository-visible decision path of the ABS Core engine.

Current execution model

The visible engine logic is deterministic and relatively simple:

1. parse the incoming request JSON;
2. parse the active policy JSON;
3. evaluate a small set of policy constraints;
4. return a structured result.

Currently visible policy checks

Based on the repository-visible engine path, the current evaluator checks:

• token limits (max_tokens);
• explicitly forbidden actions (forbidden_actions);
• and allowed tool lists (allowed_tools).

The result returned by the engine includes:

• allowed;
• reason;
• shadow_mode.

Important boundary

This repository-visible logic does not by itself demonstrate:

• a compiled policy DSL;
• instruction counting / fuel metering;
• host-level sandboxing;
• or a complete end-to-end gateway latency path.

Those may exist elsewhere in the broader project vision, but they should not be presented on this page as already proven by the current engine implementation.

Why this still matters

Even in its current form, the engine has value because it provides:

• deterministic policy evaluation;
• explicit deny reasons;
• shadow-mode behavior for staged rollout;
• and a small, auditable decision surface.

That is more defensible than probabilistic safety filtering, but it is still narrower than a full runtime kernel claim.