What Is an OOS File? The New Standard for AI Organizational Intelligence

Every major coordination system has a standard file format. The web has HTML. APIs have OpenAPI. Configuration has YAML. Data interchange has JSON. But until now, there was no standard format for capturing how an organization's AI agents coordinate. No structured way to encode the rules, the failure modes, the confidence levels, the evidence behind every operational decision an AI team makes.

The OOS file fills that gap.

An Organizational Operating System file is not documentation. It is not a wiki page or a README. It is a structured, machine-readable artifact that captures the coordination intelligence of an AI-native organization. And it is designed from the ground up to be portable, diffable, and comparable across organizations.

The Format

An OOS (Organizational Operating System) file is a structured document that uses YAML frontmatter and Markdown-formatted claims. The frontmatter captures metadata about the organization: name, industry, size, template type, agent count, version number, and word count. This header alone tells you enough to categorize and compare the file before reading a single claim.

The body contains knowledge claims. Each claim is a self-contained unit of operational intelligence. It has a claim ID for referencing, a section for categorization, the rule itself, the reasoning behind the rule, the failure mode that occurs when the rule is violated, a confidence level, an evidence type, and a scope defining which agents or teams the rule applies to.

The combination of YAML frontmatter and structured claims makes the OOS file both human-readable and machine-parseable. You can open it in any text editor. You can also feed it to an AI system that extracts, indexes, and compares every claim automatically.

What Makes It Different from Documentation

Traditional documentation describes what a system does. An OOS describes what a system knows. That distinction matters.

A wiki page might say: "Agents write to shared state files." An OOS claim says the same thing, but adds six dimensions that plain text cannot. It tells you the confidence level. It tells you the evidence type. It tells you the failure mode. It tells you why the rule exists. It tells you the scope. And it gives the claim a unique identifier so it can be tracked, compared, and referenced across organizations.

Documentation decays. Nobody knows which parts are current, which are aspirational, and which are wrong. An OOS file makes these distinctions explicit. A HIGH confidence, MEASURED_RESULT claim is fundamentally different from a LOW confidence, SPECULATION claim. Both are valid. But they carry different weights, and the format makes that visible.

The Claim Structure

Here is what a single claim looks like in practice:

Each field adds a dimension that plain text documentation cannot provide. The claim ID makes it referenceable. The section makes it categorizable. The rule states the operational truth. The why explains the reasoning, so a new team member or a new AI system can understand the intent, not just the instruction. The failure mode documents what actually goes wrong when the rule is violated. This is operational knowledge that most organizations lose.

The confidence level tells you how certain the organization is. HIGH means it has been validated through measurement or extensive observation. MEDIUM means it is an observed pattern with reasonable evidence. LOW means it is an inference or speculation. The evidence type tells you how the claim was established. MEASURED_RESULT means someone ran the numbers. OBSERVED_REPEATEDLY means it kept happening. SPECULATION means the organization is being honest about what it does not yet know.

Together, these fields turn a simple rule into a structured, comparable unit of organizational intelligence.

Why Files, Not APIs

OOS files are portable. You can store them in git. You can diff two versions to see exactly what changed between releases. You can share them over email, paste them into a chat, or host them on a static server. No platform account required. No API key needed to read one.

The file format is the protocol. Any AI system that understands YAML and Markdown can parse an OOS file. Any diff tool can compare two versions. Any version control system can track the history. This is intentional. The value of coordination intelligence increases when it moves freely between systems, not when it is locked behind a proprietary API.

OTP is the first platform that reads, indexes, and compares OOS files at scale. But it is not the only system that can. That is the point.

Token Efficiency Built In

Every claim in an OOS file has a measurable token cost. When you load a rule into an AI agent's context window, it consumes tokens. Those tokens are a finite resource. The question is whether each rule earns back more than it costs.

Because claims include confidence and evidence metadata, you can calculate the Token Efficiency Ratio for each rule. A HIGH confidence, MEASURED_RESULT claim that prevents a documented failure mode returns 10x its token cost. A LOW confidence, SPECULATION claim that has never been validated returns 0.5x at best. The ratio tells you which rules are earning their keep and which are dead weight in your context window.

This means organizations can treat their OOS like a budget. High-performing rules stay. Low-performing rules get validated or removed. The format itself enforces the discipline.

The Standard Is the File

The OOS file is not proprietary. It is a format. Any AI system can read it, compare it, and learn from it. Any organization can generate one. Any version control system can track its evolution. Any diff tool can show you what changed.

That is the point. Coordination intelligence should not be locked inside any single platform, any single vendor, or any single AI model. It should live in a portable, structured, versioned file that the organization owns and controls.

Publish yours.