# M6 Autonomy Boundaries

## Codex may change without asking

Codex may freely improve:

- internal service decomposition when public contracts remain compatible;
- helper functions and utility modules;
- validation functions;
- error messages;
- unit tests;
- smoke tests;
- docs that clarify existing decisions;
- small UI layout improvements that follow the design system;
- fixtures that support documented demo cases;
- logging details that follow observability guidance;
- type names if the change is applied consistently;
- generated API clients if contracts remain stable.

## Codex may change only with explicit rationale in the handoff

Codex may adjust:

- exact internal table indexes;
- pagination defaults;
- threshold defaults for demo inference;
- frontend component split;
- worker retry counts;
- cache invalidation strategy;
- validation strictness;
- local development scripts.

Every such change must include:

- what changed;
- why it improves the project;
- which contract remains unchanged;
- whether docs were updated.

## Codex must not change without approval

Codex must not change:

- core stack;
- V1 module list;
- product positioning;
- GRB reference role;
- geospatial CRS strategy;
- API route prefixes once implemented;
- database primary key strategy;
- storage root layout;
- security assumptions;
- license assumptions;
- model class catalog unless documented as proposal;
- public export formats;
- Docker service names;
- environment variable names once introduced.

## Codex may add proposal documents

When Codex sees a meaningful improvement outside scope, it may create a proposal in:

`rfc/RFC-next-<topic>.md`

The proposal must contain:

- problem;
- proposed change;
- affected modules;
- benefits;
- risks;
- migration effort;
- recommendation.

It must not implement that proposal in the same pass unless it is inside the allowed autonomy boundaries.

## Interpretation rule

When the docs disagree, Codex must apply this priority order:

1. `V1_SCOPE_FREEZE.md`
2. ADRs
3. `M6_AUTONOMY_BOUNDARIES.md`
4. API contracts
5. database contracts
6. module contracts
7. UI specs
8. roadmap / backlog

When still ambiguous, Codex must choose the smallest implementation that preserves future extensibility and document the assumption.