Common Fabric: A runtime where data, not software, carries the trust policy

The problem: software is trusted, and that is the flaw

Every networked system today operates on a single rule: you hand your data to software and you trust that software. Common Fabric starts from the opposite position. The README states it plainly: the software is untrusted, and safety attaches to the data. Each datum carries its own policies, anything derived from it carries those policies too, and code that cannot prove it honors those policies does not compile. That is a fundamentally different contract. The target user is a developer building collaborative systems where multiple parties contribute code or data and no single party can vouch for all of it. The project is explicitly early and fast-moving: the README warns there is no API stability yet. If you need a production-grade runtime, this is not it. If you want to explore a different trust model, this is the place.

Inverting trust: data carries policy, code must prove compliance

The core mechanism is that policies travel with data, not with the programs that process it. When a pattern transforms data, the derived output inherits the policies of its inputs. The compiler enforces this: code that cannot demonstrate it honors those policies fails to compile. This is a compile-time check, not a runtime audit. The README refers to a real pattern in the repository, what the compiler emits for it, and where the runtime checks the result. That is the key architectural move. The runtime and storage layer are both part of Common Fabric, so the enforcement is not bolted on at the edge. It is in the data plane. This is a hard design choice with real consequences for how you write patterns. You cannot just write a function that manipulates data and hope the policy is respected. The compiler will reject it if the policy is not provably honored.

Patterns, pieces, and spaces: the three abstractions

Common Fabric has three core concepts. Patterns are reactive programs written in TypeScript (TSX) that run in a secure sandbox. They can process data, render interactive UIs using cf- prefixed components, react to changes from linked patterns, and connect to external APIs. Pieces are deployed instances of patterns running in Common Fabric spaces. Spaces are collaborative environments where pieces live and interact. The data flow is automatic: when you link pieces, data flows between them without manual orchestration. This is a reactive model, closer to spreadsheet dependencies than to request-response. The sandbox is a critical detail because it is what makes untrusted code viable. If code can only run in a secure sandbox, then the policy enforcement has a boundary to enforce against. The README does not specify what the sandbox restricts, so you should verify that before relying on it for anything sensitive.

Getting started: mise, Deno, and a local dev script

The quick start is concrete and toolchain-specific. You need mise, a version manager, and you must activate it in your shell. Clone the repo, run mise trust && mise install to pin the Deno version, then optionally install Git hooks with deno task install-hooks. mise puts the repo's bin/ on PATH so cf works as a plain command. Without mise, you run deno task install-cf. Then start local dev servers with ./scripts/start-local-dev.sh and access the app at http://localhost:8000. The backend can also be run manually from packages/toolshed with deno task dev. If you contribute without commit access, you do not need a test-records key; CI records your pull requests' runs. That is a thoughtful touch for external contributors.

The monorepo: Toolshed, Shell, CLI, and UI components

The repository is a multi-package monorepo. The backend is Toolshed, written in Deno2, and provides the distributed runtime and storage. The frontend is Shell, a web client built with Lit Web Components. The CLI, cf, manages pieces, links patterns, and deploys to spaces. There is also a custom VDOM layer and cf- prefixed components in packages/ui, and example patterns in packages/patterns. The split is clear: runtime, client, tooling, and examples. The CLI is the primary interface for deployment, so you will spend most of your time there. The README points to deno task cf --help for the command reference. That is the first thing to run after setup.

AI-assisted development is a first-class feature

Common Fabric is built with AI assistance in mind. The repository includes repo-local skills for pattern development, testing, and deployment. These are surfaced through Claude Code commands like /pattern-dev, /pattern-test, and /pattern-deploy. There is also /start-local-dev, /deps, and /oracle for investigating how things actually work. Codex discovers these skills through /.agents/skills/, while Claude compatibility preserves the /pattern-dev names. This is not a bolt-on. The development workflow assumes you will use an LLM to write patterns. That is a bold bet, and it matches the project's philosophy: if code is untrusted, you might as well generate it with an untrusted model and let the compiler check it. The README does not say how well the skills work, so you should test them yourself.

What is not built yet: the honest gaps

The README is refreshingly honest about what is missing. The how-it-works document is described as showing what is not built yet. That is a rare admission. The project is nascent, and the interfaces change often. There is no API stability. That means any code you write today may break with the next push. The release list shows a Loom embedding runtime for macOS 14 arm64, which suggests the project is also targeting local AI models, but the README does not explain what Loom is. The docs point to a long-form document about the physics and hardware, but the README does not summarize it. If you need to know what the hardware requirements are, you will have to read that document yourself.

Alternatives: what else gives you policy-carrying data?

There is no direct equivalent to Common Fabric that is stable and production-ready. The closest conceptual alternatives are policy-as-code frameworks like Open Policy Agent (OPA), which let you write policies that are evaluated at runtime. OPA is a decision engine, not a data-carrying policy system. It does not attach policies to individual data items. Another alternative is confidential computing, where hardware enclaves protect data in use, but that is a hardware trust model, not a compiler-enforced one. Common Fabric's approach is different: it moves enforcement to compile time and attaches policies to data. If you need runtime policy evaluation today, OPA is a mature choice. If you want compile-time enforcement, you will have to wait for Common Fabric to mature or build something yourself.

Licence and maintenance: 0BSD and a fast-moving repo

The project is licensed under 0BSD, which is a permissive license with no conditions. That is a low barrier for adoption. The repository is not archived, and the last push was August 2026, so it is actively maintained. The release cadence is irregular, with releases named by date or by build number. The maintenance cost is high for adopters because there is no API stability. You will need to track changes closely. The README does not mention a deprecation policy or a migration guide. The test-records system suggests the team cares about flaky tests, but that is not a substitute for a stable API. If you adopt this, plan to fork or pin a specific commit.

Editorial conclusion

Adopt Common Fabric if you are building collaborative data pipelines where you cannot trust every piece of code and you are comfortable rewriting against a moving interface. Do not adopt it for production workloads: there is no API stability, the documentation explicitly says interfaces change often, and the only supported path is a local dev setup with Deno and mise. Before committing, verify that the policy-carrying data model actually compiles for your use case by running the examples in packages/patterns, and confirm that the 0BSD license and the current toolchain (Deno 2, mise) fit your stack. If you need a stable, battle-tested distributed runtime today, look elsewhere.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes