Engineering Standard — Execution Receipt Taxonomy¶
Purpose¶
Execution receipts must clearly distinguish repository-owned work from platform-owned operations and deployment state.
Agents must not classify infrastructure or deployment questions as implementation defects.
This taxonomy is mandatory for all execution agents.
Readiness Model¶
Every execution receipt must report three independent readiness states.
| Readiness | Meaning |
|---|---|
| Implementation Readiness | The repository work is complete. Code, tests, reviews, and required CI have reached their expected state. |
| Infrastructure Readiness | The platform is capable of executing or deploying the implementation. |
| Production Readiness | The implementation is both complete and deployable into the intended environment. |
These states are independent.
Implementation MAY be complete while Infrastructure Readiness is blocked.
Infrastructure MAY be ready while implementation remains incomplete.
Production Readiness requires both.
Classification¶
Every unresolved item MUST belong to exactly one category.
1. Implementation Defect¶
Repository-owned.
Examples:
- incorrect code
- failing unit tests
- invalid CI configuration
- missing files
- review findings introduced by the current merge request
- broken deployment scripts owned by the repository
These are fixed inside the repository.
2. Infrastructure Authority Decision¶
Platform-owned.
These are operational ownership decisions, not implementation defects.
Examples:
- runner registration
- Cloudflare ingress ownership
- DNS allocation
- reverse proxy ownership
- OCI credential authority
- secret ownership
- deployment target ownership
- platform service registration
Repository implementation must not invent or bypass these decisions.
If unresolved, record them as:
Infrastructure Authority Decision
Do not rewrite repository code to compensate.
3. Deployment Inventory¶
Environment-owned.
Questions about the current state of a deployment are inventory, not architecture.
Examples:
- which host currently runs a service
- which City instance is active
- which endpoint_origin mode is configured
- what containers currently exist
- which version is deployed
- service health
- published artifact count
Inventory answers come from runtime inspection.
Do not classify inventory gaps as architecture defects.
4. Architecture Gap¶
Documentation-owned.
An Architecture Gap exists only when the authoritative specification does not define ownership, lifecycle, mutation authority, or invariants.
Examples:
- undefined ownership
- missing mutation rules
- undocumented command migration
- absent lifecycle specification
Questions answerable through deployment inspection are not architecture gaps.
Receipt Structure¶
Execution receipts should use the following order:
- Implementation Readiness
- Infrastructure Readiness
- Production Readiness
- Implementation Defects
- Infrastructure Authority Decisions
- Deployment Inventory
- Architecture Gaps (if any)
- Remaining Blockers
- Terminal State
Decision Rules¶
Agents must:
- fix only Implementation Defects within the authorized scope;
- record Infrastructure Authority Decisions without attempting to implement platform policy;
- answer Deployment Inventory questions through evidence gathered from the running environment;
- classify an Architecture Gap only when authoritative documentation is genuinely silent.
Agents must not compensate for missing infrastructure by changing repository implementation.
Governing Principle¶
Repository ownership, infrastructure ownership, deployment state, and architecture are separate concerns.
Execution receipts must preserve those boundaries.