# Adjacent practices

> How BROCS sits with DevOps, SRE, SecOps, platform engineering, and the compliance frameworks you already answer to.

Source: https://brocs.fyi/resources/adjacent-practices/
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---


BROCS is not a replacement for anything. Every letter has a mature discipline behind it
that has already solved most of the problem for non-AI systems. The value of the
framework is in naming which parts transfer unchanged, which parts need amendment, and
which parts are genuinely new.

If you have a strong platform practice, you are further along than you think. If you
have none, do not start with AI; start with the adjacent discipline.

## DevOps and DORA (Build)

**Transfers unchanged.** Lead time for changes is the single most useful metric to carry
across. The question &#34;how long from someone having an idea to that idea running
somewhere real&#34; works exactly as well for an AI app as for a service, and the answer is
usually worse.

**Needs amendment.** The DORA population is engineers. The Build surface includes people
who are not engineers and will never open a terminal, and a golden path they cannot walk
is not a golden path. Measure lead time for the analyst as well as for the platform
engineer.

**Genuinely new.** The artifact under change control is now partly English. A prompt is
executable, and the review process that reads a code diff carefully will skim a prompt
diff. The [Amazon Q wiper incident](/resources/failure-modes/#amazon-q-wiper) is that
gap, shipped to a million installs.

## SRE (Run and Observe)

**Transfers unchanged.** Error budgets, golden signals, blameless postmortems, and the
principle that reliability is a feature you spend on deliberately. Also the discipline
of testing restores rather than trusting backups.

**Needs amendment.** The golden signals need company: tokens, cost per request, tool
calls, and refusal or failure rate. Saturation means something different when the
constrained resource is a provider rate limit you do not control.

**Genuinely new.** Correctness is a spectrum and it moves on its own. A service that
returns 200 with a subtly worse answer than last week is a new failure mode. It looks
like nothing on a traditional dashboard, and the first report usually comes from a
customer. That is why evals belong next to monitors.

## SecOps and the OWASP LLM Top 10 (Secure)

**Transfers unchanged.** Least privilege, defence in depth, credential rotation, and the
habit of asking what a component can reach before asking whether it is trusted.

**Needs amendment.** The perimeter model assumed data moved when a human moved it. An
agent with tool access and standing permissions moves data continuously as a side effect
of doing its job, so the interesting boundary is no longer the network edge, it is the
set of things one component can touch.

**Genuinely new.** Indirect prompt injection has no clean analogue. Untrusted content is
now an instruction channel, which means every document, ticket, web page, and email an
assistant reads is a potential input to its control flow. The
[EchoLeak vulnerability](/resources/failure-modes/#echoleak) is the reference case: no
click, no attachment, just an email the assistant read.

## Platform engineering (Build and Run)

**Transfers unchanged.** Internal platform as a product, paved roads, self-service
provisioning, and the observation that the compliant path has to be the fast path or it
will lose.

**Needs amendment.** The tool layer changes faster than platform teams are used to
building for. A platform that hard-codes today&#39;s agent CLI will be a migration project
within a year. Build the substrate, not the integration.

**Genuinely new.** Very little. This is the discipline BROCS borrows from most heavily
and amends least.

## Control theory (Observe and Control)

Observe and Control are one loop, and naming them as two letters is deliberate. A system
you can measure but not adjust is a dashboard. A system you can adjust but not measure is
a guess. Most AI programs build the dashboard first and then discover that the only
available adjustment is to turn the whole thing off.

## GRC, NIST AI RMF, and the EU AI Act (Secure)

BROCS is an engineering framework, not a compliance framework, and it does not compete
with either. The relationship is mechanical: compliance frameworks tell you which
outcomes you must be able to evidence, and BROCS is about whether your platform can
produce that evidence as a byproduct of running rather than as a quarterly project.

The NIST AI Risk Management Framework organises around Govern, Map, Measure, and Manage.
Map and Measure land on Observe. Manage lands on Control. Govern lands on Secure. If you
are already running the RMF, BROCS is the question of where each function is actually
implemented in your stack.

The EU AI Act works the same way from the other direction: obligations attach to
outcomes, and the practical question is whether your system can produce records of what
it did without a person reconstructing them. That is the
[agent trace](/resources/glossary/#agent-trace), which is an Observe capability with a
Secure requirement attached.

## FinOps (Secure)

**Transfers unchanged.** Visibility, attribution, showback and chargeback, and the
cultural point that the team causing the spend has to see the number.

**Needs amendment.** Inference spend is more elastic than compute spend and can move an
order of magnitude on a prompt change, so monthly reporting is too slow to be a control.

**Genuinely new.** Agents spend money in a loop. A retry policy is now a budget decision.




