AI-NATIVE OPERATING SYSTEMS · FRAMEWORK
CLARITY turns "I have a business" into a typed, auditable specification an agent can execute and a human can trust. It produces four outputs in strict dependency order — Vocabulary → Methodology → Process → Artifacts.
Why it exists
Traditional SaaS sold humans a better screen to operate their work. Agents remove the need for the screen — and for the human to operate it.
Agents do not replace SaaS systems. They replace the need for humans to operate them.
The durable position is not owning the best application. It is owning the control plane through which agents safely execute work — the data, the permissions, the audit trail, the workflow definitions, and the execution environment itself. Build operating systems over your tools, not inside them. The tools may be replaced; the system that orchestrates them persists.
High
Workflow-heavy UI wrappers
Medium
Data-rich systems with network effects
Low
Platform / execution infrastructure
Six typed components
Every loop is built from six primitive types. Each has a defined input contract, output contract, and mapping to the CLARITY vocabulary.
C — Capture
The structured, queryable source of truth for a domain. Agents act only on [RECORD] data — never on unverified context.
A — Authorize
Who or what can take which actions under which conditions. The decision tree that governs all execution.
R + T — Route + Transfer
From trigger to resolution, including feedback. The core unit of repeatable work an agent executes.
A + I — Authorize + Inspect
A defined checkpoint where human review is required before execution continues. Routed with full context.
I — Inspect
Every action, decision, approval, and exception — written once, never overwritten. The foundation of auditability.
Y — Yield
The priceable, verifiable result the system produces per completed loop. If it cannot be measured, it cannot be priced.
Design sequence
Each step builds on the last. You cannot specify a [GATE] before you have drawn the [BOUNDARY]. You cannot define a [YIELD] before you have named the [LOOP].
01
Write a one-sentence [LOOP] definition that captures the trigger, the actor, and the end state. If you cannot say it in one sentence, the loop is not yet defined.
02
Produce a typed [RECORD] spec: fields, data types, source systems, and freshness requirements. This becomes the agent's trusted context.
03
Map roles, permissions, and risk thresholds. Define what an agent can do autonomously versus what requires escalation.
04
[GATE] definitions: what triggers each gate, who receives the routed approval, and what context they need to decide. No gate without a defined decision owner.
05
Define every event type the [TRAIL] must record: the fields per event, the retention requirement, and the query surface for audit.
06
Specify the [YIELD]: what the completed loop produces, how it is verified, and how it can anchor a pricing unit. If it is not priceable, it is overhead.
07
Define the feedback path: which [YIELD] data writes back to the [RECORD], on what cadence, and what triggers the next iteration. Feedback is not optional.
Decision methodology
Every design decision in CLARITY traces back to three governing questions. The six operating rules enforce that structure at runtime.
Human, agent, or system? Default to agent. Escalate to human only when an action crosses a [BOUNDARY] threshold. Every actor is named and authorized.
Is it in the [RECORD], the [TRAIL], or unverified? Agents act only on [RECORD] data. Everything else is a risk to be gated or discarded.
Which [YIELD] does this action serve? If none, it is overhead — justify or cut. Every step earns its place by contributing to a measurable outcome.
Doctrine
The difference between a system built for agents and one retrofitted for them is architectural. These are the positions CLARITY takes.
Method
The Business Analysis Protocol converts a real operating business into a ranked set of CLARITY loop candidates. Already used to design operating systems across multiple originated businesses.
Intake
Structured intake that maps what the business does, how work moves, and where decisions are made.
Classify
Each domain is classified by AI-fit and data readiness.
Rank
Candidate loops are ranked by yield potential, data readiness, and boundary clarity. Build the highest-ranked loop first.
Specify
One sheet per loop: the six typed components fully specified, in dependency order. The executable contract.
Pre-condition gate — Data Readiness
The [RECORD] must exist or be buildable before loop specification begins. Data readiness gates design, not deployment.
Pre-condition gate — Boundary Clarity
The [BOUNDARY] must be definable — who owns decisions, what requires human approval. Without a boundary, there is no loop.