The BROCS manifesto
The operating requirements behind enterprise AI enablement: Build, Run, Observe, Control, and Secure.
An operating model for AI
BROCS is the framework for enterprise AI enablement. It groups the work under Build, Run, Observe, Control, and Secure.
A model can generate useful work while the organization still lacks a supported way to deploy it, monitor it, change it, or account for it. BROCS gives each responsibility an owner and a test.
Build gives people a sanctioned path to create and ship AI work. Run provides the runtime, state, and placement. Observe records behavior, quality, cost, and lineage. Control manages configuration, access, routing, and rollback. Secure limits reach and produces evidence that the limits held.
Products rarely map cleanly to these responsibilities. One product may cover several, and one responsibility may span several systems. Judge coverage by what the organization can do and prove.
Systems already in use
AI operations often begin before an organization names them. A purchased or embedded AI capability can create operating responsibilities as soon as people depend on it. BROCS can set the requirements before approval or assess the current estate. The starting guide covers the onramp, and the enterprise AI operations guide covers systems in use.
Dependencies
- Build work requires a supported Run environment.
- A running system needs Observe telemetry before the team can detect changes in quality or reconstruct an incident.
- Observe data becomes useful through Control mechanisms such as rollback, routing, and access changes.
- Control relies on Secure policies and evidence to set acceptable limits.
- Secure depends on a sanctioned Build path that people will use.
Secure changes the requirements for Build, so the sequence repeats. A gap in one capability becomes an operational dependency for the others.
The commitments
- Capabilities should compose without one supplier owning the stack.
- Workloads should follow the data, policy, and jurisdiction that govern them.
- Significant actions should leave records people can inspect.
- Models, prompts, routes, and permissions should be changeable and reversible.
- Evidence should be produced during operation, not assembled afterward.
The organization owns the requirements, interfaces, placement decisions, and evidence even when suppliers provide the components. Supplier choices should remain replaceable.
Boundaries
BROCS evaluates capabilities and evidence. Vendor diagrams, policy documents, and pilots count only when the organization can show how they work in production.
Use it as a coverage test for commercial and homegrown systems. Score current practice, identify the weakest capability, and decide which missing control creates the most risk.
Use it
Score your coverage. Run the questions in an architecture review. Test the argument against the failure-mode library. Copy and challenge the framework. Correct it when a capability is wrong or missing, and correct the system when coverage is absent.
Provenance and disclosure
BROCS was created by Leo Mata and first introduced in the 2026 origin essay. Mata also builds enterprise AI infrastructure at Calliope AI. That commercial affiliation is part of the provenance record. BROCS remains vendor-neutral and gives Calliope no preferred treatment.
The framework text is published under CC BY 4.0. Reuse and translate it with attribution to Leo Mata and brocs.fyi. See how to cite BROCS, how the framework is maintained, and the version history.