OKHAM defines open contracts that act as a stable semantic boundary across tools, services, UI, and agents.
At the core of this model are shared, versioned type definitions that give systems a common semantic vocabulary. All higher-level artifacts are defined in terms of these types, allowing compatibility to be checked, composed, and reasoned about explicitly.
Because meaning is preserved as versioned, testable artifacts, systems can change behavior, adapt flows, or introduce new capabilities without reinterpreting intent or re-reading code. This allows not only human teams, but also automated tools and agents, to understand what exists, how it can be used, and how it may evolve — before execution.
Contracts decouple understanding from implementation. Meaning remains stable even as runtimes, languages, and deployment models change.
Shared components, snippets, capabilities, and business flows can be safely discovered and composed across systems.
Change implementations, architectures, and UI without breaking meaning.
Modern systems don't fail because code can't talk - they fail because meaning is implicit. OKHAM makes semantics explicit, portable, and testable. As AI agents become first-class system actors, implicit meaning becomes a critical failure mode.
In complex systems, the meaning of interfaces and data is often implicit and trapped in code, docs, and tribal knowledge. This makes interoperability, governance, and reuse expensive - especially when AI agents and tools are involved.
OKHAM defines vendor-neutral contracts that make semantics explicit and machine-readable: types, events, intent, policies, interoperable UI structures, and the supporting "glue" that makes ecosystems work - navigation, registries, validation/linting reports, function & capability metadata, design tokens, and more - independent of language, runtime, or implementation.
Contracts become shared truth: validation becomes deterministic, integrations become composable, and humans + tools + agents can collaborate with less ambiguity and safer change.
OKHAM turns meaning into versioned, testable artifacts.
It starts with shared type definitions — a common semantic vocabulary — and builds upward through events, intent, policies, functions, snippets, capabilities, business flows, registries, and UI primitives.
Because everything is defined in terms of the same types, compatibility is guaranteed by construction — not by convention.
Artifacts are curated, versioned, and validated in catalogs so teams, tools, and agents can safely discover, reuse, and compose meaning without semantic drift.
OKHAM is for systems engineers building long-lived platforms, platform teams managing complex integrations, and organizations that need to evolve systems safely over time.
It is designed for environments where meaning must remain stable even as implementations, architectures, languages, and infrastructures change.
For systems engineers and platform teams, OKHAM provides a stable semantic boundary — similar in spirit to an ABI, but for meaning rather than binaries. Contracts define what things mean and how they can be safely composed, so refactors, migrations, and parallel development can happen without breaking consumers.
For tooling developers and automation systems, OKHAM exposes meaning as explicit, machine-readable artifacts. Tools no longer need to infer intent from code or documentation — they can read contracts, validate compatibility, and reason about change deterministically.
For AI agents, this is critical. An agent can understand a system by reading its contracts: types, events, intent, policies, UI semantics, and capabilities — without inspecting source code. This enables safer planning, impact analysis, change proposals, and orchestration, because the agent operates on declared meaning rather than guessed behavior.
In short, OKHAM is for teams and tools that need systems to be understandable, evolvable, and governable — not just executable.
OKHAM is designed for reuse at the semantic level.
Teams do not just share code — they share meaningful, validated artifacts.
These artifacts live in registries and catalogs, are versioned by contract, and can be safely composed without bespoke integration work.
All of these are validated, linted, and versioned — so reuse does not degrade meaning.
When snippets, functions, UI components, capabilities, and business flows are defined in terms of the same type contracts, they become compatible by construction.
This means:
OKHAM contracts define semantic meaning, not implementations. This plane includes shared type contracts (OTC) as the foundational semantic vocabulary; event contracts (OEC) describing observable facts and causality; intent contracts (OIC) expressing purpose and expectations; policy contracts (OPC) defining constraints and permissions; and UI semantic contracts (OUCC) describing rememberable UI meaning, not rendering technology.
These contracts are versioned, validated, linted, and published as canonical artifacts. All compatibility and reuse flow from this plane. Contracts are the single source of truth; everything else is replaceable.
OKHAM systems maintain live catalogs built from published contracts. Capability registries (often backed by KV stores) track which capabilities, versions, and artifacts exist, and registries capture dependencies, compatibility, conflicts, and deprecations.
Discovery mechanisms and buses (for example, NATS for events and RPC) keep catalogs current and connect capabilities. Flow orchestration uses contracts to compose operations safely, and policy enforcement happens here before execution. This plane is often implemented by a Brain, but the function is what matters.
Execution is intentionally decoupled from meaning. Capabilities can run as containers, binaries, edge functions, or other runtimes. Examples include Go + NATS deployments, serverless runtimes, or Cloudflare Workers, and multiple runtimes can coexist while implementing the same contract surface.
Execution runtimes never embed semantic rules. They implement contracts.
UI in OKHAM is not a fixed shell. UI components are published as versioned, portable bundles and can be rendered on the client, server, or edge. The same UI semantics can be implemented using different component systems (native, React, templ, etc.).
UI reacts to events and flows, not ad-hoc API calls. Rendering is driven by contracts and shared types, not hardcoded routing or bespoke frontend logic.
The Brain is the layer where understanding, orchestration, and decision-making happen. It reads contracts, catalogs, compatibility graphs, and policies to coordinate behavior across the system.
It turns static, versioned meaning into coordinated behavior. The Brain can be centralized or distributed, embedded inside capabilities or external, and implemented as human-driven logic, rule-based systems, AI-assisted reasoning, or hybrid approaches.
The invariant is strict: the Brain never reasons over code — it reasons over contracts, types, and catalogs.
The Brain is a role, not a product. There is no mandatory Brain implementation. Any system, service, or agent that fulfills this role is “the Brain,” preserving architectural freedom and avoiding lock-in.
OKHAM does not define how the Brain is implemented — it defines what the Brain can safely reason about.
CSIL (Capability Self-Improvement Loop) is not a built-in feature and not an autonomous behavior. It is a natural consequence of explicit, machine-readable semantics combined with a Brain that can reason over contracts.
When meaning is versioned, validated, and discoverable, systems can safely propose and evaluate change.
CSIL is a governed improvement loop:
All change is mediated through contracts, versioning rules, compatibility constraints, and policy enforcement. Evidence is required; nothing changes implicitly.
CSIL can be AI-assisted, but it is never free-form self-modification. It is contract-governed, policy-constrained, and auditable by design.
OKHAM does not give systems freedom to change blindly — it gives them the ability to understand themselves well enough to change safely.
Meaning is stable and versioned.
Execution is dynamic and replaceable.
Contracts define compatibility; runtimes implement behavior.
The same semantic contracts can be executed across containers, serverless, or edge runtimes without semantic drift.
Deterministic validation replaces implicit assumptions. Shared, versioned types eliminate semantic ambiguity. Packaging and deployment are portable because meaning is externalized. Event-driven orchestration allows evolution without tight coupling.
Teams reuse validated meaning (types, flows, UI semantics), not just code, so integration shifts from interpretation to validation.
OKHAM is not a framework; it is a contract-defined semantic system that allows safe evolution across runtimes, infrastructures, and UI environments. For the full normative specification, see Core Standards.
Browser, native, or hybrid — same semantics
In OKHAM, UI is not tied to a specific frontend framework or client type.
An OKHAM UI client is any runtime that can discover UI artifacts via catalogs, validate them against contracts, render them using a compatible component system, and interact with the system through declared semantics rather than ad-hoc APIs.
A client can be a web browser, a native application using platform components, or a hybrid runtime combining both. All of them operate over the same semantic contracts.
Early experiments compared traditional server-rendered HTTP UI with local rendering of equivalent UI components. Metrics tracked CPU time per request, memory per request, and server occupancy during interaction bursts.
Results depend on workload and implementation and should be validated per system.
These effects come from moving deterministic UI work from the server to the client while preserving shared semantics. Servers execute fewer per-interaction computations, UI becomes reproducible by version, and the system avoids re-synthesizing meaning on every request.
In OKHAM, AI-driven systems are first-class clients of the semantic model and act as governing actors over system behavior.
Because capabilities, flows, and policies are described by explicit contracts and shared types, an AI system can understand what exists, what it does, and under which constraints it can be used — without inspecting source code or inferring behavior.
An AI client can reason over catalogs and contracts to:
Decisions are driven by declared intent, compatibility rules, and policies — not by hardcoded logic or opaque heuristics.
This aligns with the Brain as a reasoning role and with CSIL as a consequence of explicit, machine-readable meaning, while execution remains deterministic, validated, auditable, and contract-governed.
AI does not replace the system’s architecture — it operates within it.
In this model, AI governs meaning, not code.
This is a reference stack showing the model in action, not a polished product.
OKHAM.org is the standards foundation. If you want tooling + registries + reference implementations, go to okham.io.
Brain + NATS + 2 capabilities + UI shell.
Available soon.
Watch it appear in navigation automatically via the catalog — no wiring, no manual integration.
Same contracts. No breakage. Reused contracts, same behavior.
OKHAM is designed for reality: large teams, long-lived systems, and AI-native tooling that needs deterministic guardrails.
Instead of relying on conventions and ad-hoc integrations, OKHAM provides stable, versioned contracts that can be validated deterministically.
Standards are published as canonical JSON Schemas and documentation, and can be exposed through a read-only MCP profile (OMP) so LLM hosts and agent tooling can retrieve authoritative sources without synthesis.
Standardized packaging makes artifacts portable across environments and teams. Manifests and conventions allow tools and agents to discover what's inside, how to validate it, and how to deploy it - without guessing.
Validate compatibility with schemas and conformance rules. Catch breakage early, automate checks, and make "meaning" testable.
Use contracts as a shared interface between services, tools, and agents - without bespoke mapping logic for every pair.
Versioned meaning enables safe change: deprecations, migration paths, policy constraints, and audit-friendly evidence - without breaking consumers.
OKHAM is built for reuse: functions, components, apps, and capabilities can be published as standard artifacts and discovered via registries. This reduces duplication and turns "best practice" into something shareable and testable.
Reusable components can be previewed and iterated quickly in local tooling, which dramatically reduces latency and noise during development. The result: faster iteration, lower cost, and fewer surprises at integration time.
Less ambiguity, more leverage: reuse contracts across teams, runtimes, and tools - and keep the meaning intact.
Faster onboarding, less ambiguity, safer refactors, and reusable patterns across projects.
Deterministic validation loops, lower prompt complexity, and a shared contract model that enables consistent governance and automation.
Vendor-neutral interoperability: registries, templates, and compatibility checks that survive stack changes and organization boundaries.
Clear, auditable meaning: policies, obligations, and evidence models that can be reviewed and validated, not guessed.
Move faster with less fear: versioned contracts create stable seams for parallel work and safe migrations.
Translate an application from one architecture to another without losing meaning: contracts preserve intent, types, and constraints across refactors.
The same function, snippet, or capability can be reused across languages and stacks when its semantics are standardized.
Components can be rendered locally and reused like native building blocks. This reduces network and compute waste, enables seamless transitions between web and local UI, and keeps workflows responsive.
When agents know what each component/function is for, results become more accurate with fewer tokens spent on re-explaining context.
Common components can ship with consistent accessibility semantics and evidence expectations, raising the baseline for everyone.
Shared repos (snippets, functions, components) can follow a clear linting/verification workflow so consumers trust what they reuse.
OKHAM standards are contracts: versioned, machine-readable specifications that define semantics (meaning), not implementation details. OKHAM standards describe semantics, not execution: they are designed to be implemented across different runtimes and infrastructures. Each standard has canonical documentation and (where applicable) JSON Schemas for deterministic validation.
These contracts preserve semantic meaning across system boundaries - enabling interoperability, governance, and reuse.
Same specifications, grouped by concern to make the system easier to reason about.
Layer 1 — Semantics: OTC / OEC / OIC / OPC
Layer 2 — Apps & Capabilities: OAP / OCC / OBC / OPRC
Layer 3 — Tooling & UI: OUCC / ONC / OSR / OFR / OVR / OLR / OMP
Canonical type definitions with semantic meaning. Preserves data structure and semantics across system boundaries.
Learn more →Observable, versioned events as immutable facts. Defines event structure, causality chains, and semantic classification.
Learn more →Declarative policies that constrain, allow, deny, or condition behavior. Engine-independent policy semantics.
Learn more →Declarative intent semantics across agents and runtimes.
Preserves purpose, expectations, and constraints of reasoning and action.
Optional contracts that extend OKHAM Core for specific domains:
Declarative business flow composition and orchestration. Enables process modeling with semantic meaning preservation.
Learn more →Normative accessibility obligations and evidence model. Defines requirements and compliance verification for UI and interactions.
Learn more →Application/package manifest for portable packaging and deployment of OKHAM artifacts.
Learn more →Draft
Interoperable formats for tooling, registries, and development workflows:
A read-only MCP profile for exposing OKHAM standards to LLMs and agent tooling with authoritative, non-synthesized responses.
Learn more →Draft
Declarative specification of navigable structure and flow (screens, routes, parameters, transitions), independent of rendering technology.
Learn more →Draft
Declarative, interoperable UI component structures. Preserves component semantics across rendering engines.
Learn more →Draft
Meta-format for all OKHAM specifications. Defines structure, versioning, and documentation standards for contract documents.
Learn more →Capability packaging and discovery metadata. Optional format for registries and ecosystems to catalog and discover capabilities.
Learn more →Shared visual token vocabulary for consistent theming. Standardizes tokens (colors, spacing, typography) across implementations.
Learn more →Draft
Interoperable snippet catalog format. Enables sharing and discovery of reusable code snippets, templates, and patterns.
Learn more →Draft
Interoperable report and ruleset formats. Standardizes validation results and linting rules for consistent tooling integration.
Learn more →Draft
Declarative specification of executable operations, including inputs, outputs, side effects, and intent compatibility, independent of language and runtime.
Learn more →Draft
Contract for projections: turning streams of facts/events into derived, queryable state while preserving meaning and traceability.
Learn more →Draft
okham.org defines the standards. okham.io is where the ecosystem runs: tooling, registries, reference implementations, and reusable artifacts.
Linters, validators, CLIs, and developer utilities that implement OKHAM standards.
Shared libraries of functions, components, and capability packages - so teams reuse meaning, not just code.
Community and reference implementations aligned to the contracts - portable across stacks.
OKHAM.org is the standards body. We define open, vendor-neutral contracts (schemas + normative docs) so AI-native systems can share meaning, validate compatibility, and evolve safely.
Schemas + specifications that define semantics. Versioned, portable, implementation-independent.
Contracts are served as stable URLs and can be retrieved programmatically via MCP for deterministic agent/tool workflows.
Clear versioning and lifecycle expectations so teams can adopt OKHAM without surprises.
Standards, not software. OKHAM.org defines contracts. Implementations live in the ecosystem (see okham.io).
If you want to understand OKHAM, start with the Foundation. If you want to run it, go to okham.io.
Start with the Foundation section to understand the core principles and architecture. Then scan the Core Standards if you want the normative model.