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

Editorial thesis, proof-safe boundary.

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 compliance approval, 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.

Where this maps.

Maps to Company AI OS. Product relevance: HELM AI Company OS. Status: GATED. Horizon: COMMERCIAL.

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

A should-vs-is engine compares intended work with observed work. The should side captures reviewed intent. The is side captures source-backed state. Governed execution closes the gap only when the boundary can prove the action is allowed.

Why it matters now

  • A plan without observed state can execute the wrong fix.
  • Observed state without reviewed intent can turn dashboards into accidental authority.
  • The gap between should and is needs evidence before closure, not only a model explanation.

Boundary and evidence

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

Company OS can organize this loop around generated specs, company artifacts, approvals, notifications, and receipts. HELM still governs the action at the execution boundary.

Product map

Read from queryable company to executable organization for the broader transition from read-path software to governed write-path work.

The operating rule is consistent across the library: research can frame the question, but execution claims need source-owned proof. Look for policy checks, approval state, connector contracts, receipt hashes, replay evidence, or a clearly labeled product surface before treating an idea as current capability.

Request architecture review Back to Research