Principles and design

OCC's architecture is not a collection of disconnected design choices. It follows from a small set of principles. Each one points to a real failure mode in current AI systems, and to a concrete countermeasure in the code. This page explains those principles and the choices they justify.

Provenance over plausibility

Modern language models are trained on a vast corpus, much of it scraped from the open web, and they answer by producing statistically plausible text. They do not, in general, know where their facts come from. They cannot cite a source. They cannot tell you whether a claim is supported, contested, or invented.

This is acceptable for casual use. It becomes dangerous as soon as the answer matters.

A direct consequence of this principle is OCC's defense against GEO — Generative Engine Optimization, the practice of injecting content into the open web specifically to manipulate what AI systems say about a topic. A model that crawls the web is permanently exposed to GEO. OCC is structurally immune: Nodes do not crawl the web. They draw only from packs the community has explicitly approved. Manipulating OCC requires getting a malicious source past public review — orders of magnitude harder than seeding a few SEO-optimized pages.

Local over cloud

The default deployment of OCC runs on the user's machine. The local language model produces the answer. The user's queries do not go to a central inference service. The user's data does not feed a training pipeline.

The broker exists, but it is not where inference happens. It hosts published packs and coordinates peer connections. The query and the answer never live there.

Deliberation over single-shot

A single language model answering a question is a brittle system. Errors in retrieval, hallucinations of specifics, missed nuance — all flow straight to the user with no second opinion.

OCC treats answering as a deliberation among multiple agents:

• An Expert drafts an answer from the retrieved knowledge.
• A Critic reviews the draft against the same sources, flagging unsupported or contradicted claims.
• A Synthesizer integrates the draft and the review into a final answer.

Each role has a specialized prompt and a different cognitive task. The Critic, in particular, has access to a verbatim verification tool: if it suspects a specific claim (a date, a citation, a quoted phrase) is not in the source, it can fetch the relevant page in full and check.

The result is that small local models punch above their weight. Failure modes that would be invisible in a single-shot answer get caught in the Critic step. When a more powerful peer is available on the network, it can take the Critic role over an end-to-end encrypted exchange — turning the network's collective hardware into an effective quality gate.

Adaptability over minimum specs

OCC is designed to be useful on the hardware people actually have. There is no minimum GPU, no required cloud subscription, no list of "supported" machines that excludes the majority of users.

The Node detects the available VRAM and selects a tier, from micro (CPU-only laptops) up to server-l (multi-GPU machines). Each tier picks a Qwen variant that fits, sets context windows that won't overflow memory, and adjusts the retrieval and deliberation budgets accordingly. A modest machine retrieves less material and produces shorter answers; a powerful machine ingests more and produces deeper ones. Both are useful.

This adaptability extends to the network. A node on modest hardware can still benefit from Critic reviews performed by peers on stronger machines. Hardware inequality becomes a resource the network can balance, not a barrier to participation.

Open over closed

OCC is fully open source. The Node, Forge, the broker, the pack format, and the registry are all public, versioned, and reviewable.

The model layer is open too — OCC standardizes on the Qwen family precisely because the weights are inspectable and redistributable. The standardization is intentional: a network where every node answers through the same family of models has predictable behavior, consistent multilingual coverage, and shared multimodal capabilities. The choice of Qwen is not a limitation; it is what makes the rest of the architecture coherent.

Openness is not a feature OCC adds. It is the substrate the project is built on. Every layer can be inspected, forked, and improved.

Commons over central authority

The broker is not the authority in OCC. It is a coordinator: it serves the packs, exposes a search index, and helps Nodes find each other. If it disappears, the packs remain — they are normal files, version-controlled in a public repository, and any operator can host a replacement broker.

Authority lives in the registry (which sources the community accepts) and in the packs (the curated knowledge built from those sources). Both are public, both are versioned, both are governed by review processes anyone can participate in.

What follows

These principles produce specific architectural choices, which the rest of the documentation explains in detail:

• How OCC works walks through the end-to-end flow.
• Knowledge retrieval details the Karpathy-inspired pack format and multi-pack search.
• Multi-agent deliberation covers the Expert / Critic / Synthesizer pipeline.
• Governance describes the source registry, pack review, and the role of maintainers.
• Security and privacy maps each privacy claim to where it lives in the code.

Anything currently aspirational rather than implemented is called out in the Roadmap.