geointel/docs/16-autonomy-governance/AUTONOMY_BOUNDARIES.md

Autonomy Boundaries for Codex

Codex should be proactive, but not uncontrolled.

Green zone — Codex can decide

• function and class names when consistent with docs;
• internal helper extraction;
• validation improvements;
• error message clarity;
• test fixture additions;
• component decomposition;
• minor styling improvements;
• logging improvements;
• dependency pinning within the approved stack.

Yellow zone — Codex can decide but must document

• replacing a library with an equivalent only if dependency installation fails and the replacement stays within the stack intent;
• changing endpoint internals while preserving contracts;
• adding new tables that support existing aggregates;
• adding background job scaffolding earlier than planned;
• improving storage folder structure while preserving published paths.

Must be documented in:

• docs/CODEX_EXECUTION_LOG.md;
• CHANGELOG.md;
• relevant ADR/RFC if architectural.

Red zone — Codex must stop and ask

• changing FastAPI/React/PostGIS stack;
• removing GRB-centered QA/QC direction;
• turning the product into a generic GIS dashboard;
• removing AI pipeline readiness;
• changing V1 scope boundaries;
• adding authentication/multi-user as core V1;
• adding paid/cloud-only dependencies as mandatory;
• implementing real external downloads without source strategy and license notes;
• changing output formats away from GeoJSON/COCO/YOLO/masks without approval.

Safe fallback principle

When a dependency, data source or model cannot be used yet, implement a controlled adapter interface and deterministic fixture-backed behavior. Mark it as a scaffold, not as production-complete.