GATED

Should-vs-Is Engines

Compare planned work with real work before small gaps become big ones

Organizations need a repeatable comparison between intended work and observed work.

COMMERCIAL 5 min Intermediate Technical note
Article map
Maps to
Maps to Company AI OS
Status
GATED
Reviewed
2026-06-08

Proof-safe research note.

A should-vs-is engine compares codified company intent with actual execution state. This technical note explains the governance value of catching drift before agents or teams compound it.

Drift DetectionCompany StateWorkflow Governance

What this does and does not claim.

Does
  • Frames should-vs-is workflow governance as a research lens for governed AI execution.
  • Separates model proposal from execution authority.
  • Keeps product claims tied to current public HELM evidence surfaces.
Does not
  • Does not claim every described pattern is generally available in production.
  • Does not claim third-party certification, vendor partnership, or compliance attestation.
  • Does not make local demos, tests, or diagrams equivalent to live customer proof.

Claim, boundary, evidence implication.

Claim

Organizations need a repeatable comparison between intended work and observed work.

Boundary

This is gated Company OS direction, not a public live dashboard claim.

Evidence

A should-vs-is claim needs observed source state, generated proposals, and reviewable proof.

Diagram interlude

The system compares intended work with observed state.

Governed execution needs both the planned state and the actual company record before closing a gap with evidence.

Should-vs-Is EngineCOMMERCIALDRIFT DETECTION
HELM AI Company OS compares company policy against actual artifacts. Drift triggers governed remediation.
Should-vs-Is EngineShould-vs-Is engine: policy specification (should) is compared to actual artifacts (is), with drift triggering governed remediation through HELM.!Result updates the "Is" state
Text description
  1. Should — Company policy, approved specs, compliance requirements
  2. Is — Actual artifacts: code, docs, configs, deployments
  3. Compare — AI finds mismatches between should and is
  4. Draft Fix — AI proposes a remediation
  5. HELM Check — Fix passes through execution boundary
  6. Governed Action — Approved fix is applied with proof
Open standalone diagram

At the heart of every organizational failure is a discrepancy between what should be happening and what is actually happening. Many teams find this gap by hand. That is slow and error-prone. By the time the gap is visible, work may already be off track.

Should vs Is Engines Section

The Should Engine

The Should Engine is the company’s codified intent. It encompasses policies, budgets, standard operating procedures, and compliance requirements. It defines the boundaries of acceptable behavior. In a modern architecture, this intent must be machine-readable and enforceable through policy checks.

The Is Engine

The Is Engine is the real-time observation of the company’s operational state. It tracks infrastructure changes, financial transactions, and access logs. It is the ground truth of what work is actually being executed.

Closing the Gap

The value of governed autonomy lies in the ability to continuously reconcile these two engines. When an AI agent proposes an action, it represents a potential change to the Is state. A governed execution boundary evaluates this proposal against the Should state before the action occurs. If the proposal matches the policy, it continues. If it does not, it is blocked or escalated. The goal is to catch wrong work earlier.

Request architecture review Back to Research