geointel/docs/M6_AUTONOMY_BOUNDARIES.md

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.