Operations

Day two is about authority, not promptsCopy Anchor Link

Once a repository is onboarded, an operator rarely touches a prompt. The work moves to a small set of controls that sit outside the model:

Each control is enforced by the runtime, not requested of the agent. That is the point of "Your policy decides. Not the model."

The operator's mental modelCopy Anchor Link

Think of the system as four layers, from the most permanent to the most immediate.

1. Floors. Organization-level limits that no narrower scope can raise. A floor says, for example, that high-risk work never exceeds suggestion. Lower scopes may only tighten.
2. Policy. The AutonomyPolicy assigns a ladder level per scope, risk class and environment. Policy is evaluated before every privileged action, outside the model.
3. Grants. For each work unit, the runtime derives a short-lived, narrow grant from profile, playbook step, risk and level. The agent can ask for less, never more.
4. Breaker. A customer-local switch with four positions that caps effective autonomy over everything above it, and needs no outside service to work.

Operations is mostly about the edges of these layers: tuning floors, reviewing approvals, watching for anomalies, tripping the breaker, and deciding when evidence justifies a promotion.

1apiVersion: numinance.dev/v1
2kind: AutonomyPolicy
3metadata: {name: org-ladder, scope: SCOPE_ORG}
4spec:
5  defaults: {level: AUTONOMY_LEVEL_PR}
6  rules:
7✓    - {match: {playbook: dependency-upgrade, risk: RISK_CLASS_LOW}, level: AUTONOMY_LEVEL_MERGE} (matched)
8  floors:
9    rules:
10      - {match: {risk: RISK_CLASS_HIGH}, max_level: AUTONOMY_LEVEL_SUGGEST}
11      - {match: {environment: production}, max_level: AUTONOMY_LEVEL_MERGE}

What a human is still forCopy Anchor Link

Full autonomy here is configurable, governed and human-accepted. It is never unrestricted. Humans keep four jobs that no agent identity can take over:

• Approve changes that policy routes to approval. The approver is a distinct, attributable human, never the author agent.
• Accept promotions. Evaluations can propose that a playbook has qualified for a higher level. A human accepts. Nothing promotes itself.
• Trip and reset the breaker. Reset requires a human and a reason.
• Use break-glass. A named human, time-boxed, separately logged. See Circuit breaker.

A typical week, in design termsCopy Anchor Link

• Review the approvals queue, with each request showing the plan, the evidence so far and the policy reasons that routed it to a human.
• Skim denied intents and budget exhaustions. A denial is a signal that policy worked, or that a playbook asks for more than it should.
• Check qualification per playbook. If a playbook has enough clean runs and no severe event, consider accepting a promotion. If it had a severe event, qualification starts over.
• Confirm the breaker is where you expect it, and that the runtime reports the position you set.

Failure modes operators should expectCopy Anchor Link

• Approval fatigue. If everything routes to a human, humans stop reading. Tighten playbooks and raise floors deliberately instead of approving by habit.
• Silent policy drift. A policy change is itself a change under protected paths. Review it as code, and treat a widened permission as needing re-approval.
• Over-trusting evidence. Evidence proves provenance and chain integrity under keys you pin. It does not prove the code is correct. See Evidence and trust.
• Treating the open CLI as the runtime. numi validates configuration and verifies evidence. It does not run changes. See Status.