HNC
Hecate AI Engineering Handoff and Evidence Return
1. Purpose
HNC-1.1-G defines the governed boundary between Hecate/Jira implementation orchestration and an AI engineering agent operating on a target implementation repository.
The governing rule is:
AI may implement and report evidence. AI does not certify its own completion.
Machine-verifiable evidence may establish implementation readiness. Final governed completion remains subject to the human approvals required by the Implementation Packet and organizational policy.
2. Delivery position
ZAYAZ Docs
↓ canonical truth
Hecate Need + Resolver
↓
ImplementationPacket
ValidationPlan
AgentContextPack
↓
EngineeringWorkOrder
↓
AI Engineering
↓
ZAYAZ Platform commit / PR
↓
CI / deterministic validation
↓
ImplementationEvidence
↓
Hecate Evidence Assessment
├─ remediation_required
└─ implementation_ready_for_review
↓
Human governance
implementation_ready_for_review is deliberately distinct from completed.
3. EngineeringWorkOrder
The EngineeringWorkOrder is the outbound machine contract given to an engineering agent. It is a constrained derivative of the Implementation Packet, Agent Context Pack and Validation Plan.
It contains:
- immutable Need, packet and canonical-source references;
- authorized repository and base ref;
- implementation layers;
- allowed and forbidden paths where known;
- canonical autonomy permissions;
- human and machine-derived acceptance criteria;
- forbidden changes;
- unresolved clarifications;
- required validation gates;
- the required ImplementationEvidence return schema.
The canonical schema is:
schemas/hnc/payloads/engineering-work-order.schema.v1.json
4. Autonomy enforcement
EngineeringWorkOrder permissions SHALL be resolved from the canonical HNC autonomy registry rather than inferred by an agent.
An agent SHALL NOT exceed the work-order permissions merely because its execution environment technically permits a broader action.
Examples:
implement_and_testmay modify and test but may not open a PR;open_prmay open a PR but may not merge;merge_eligiblestill requires all blocking gates and required approvals before merge;deployment_eligibledoes not bypass deployment policy or human approval requirements.
Unresolved blocking clarification prevents an actionable engineering handoff.
5. Repository boundary
The implementation repository in returned evidence SHALL equal the repository authorized by the EngineeringWorkOrder.
For runtime ZAYAZ work this will normally be:
viroway-ltd/zayaz-platform
An agent SHALL NOT satisfy a runtime work order by changing canonical architecture in zayaz-docs unless the work order explicitly targets the Governance & Contract Plane.
6. Evidence return
The agent or CI system returns the existing canonical ImplementationEvidence payload:
schemas/hnc/payloads/implementation-evidence.schema.v1.json
Evidence includes implementation repository/commit, PR reference where applicable, canonical artifact versions, gate results, CI references, deployment references and reviewer decisions.
AI prose such as tests look good is not implementation evidence.
7. Evidence assessment
Hecate SHALL deterministically assess returned evidence against the EngineeringWorkOrder and Validation Plan.
The assessment checks at minimum:
- schema validity;
- Need identity;
- Implementation Packet reference;
- canonical source commit;
- authorized implementation repository;
- evidence for every required validation gate;
- failed blocking gates;
- CI run references;
- unresolved clarification state;
- autonomy state;
- reviewer decisions when present.
The initial assessment states are:
invalid
remediation_required
implementation_ready_for_review
The evidence assessor SHALL NOT emit completed.
8. Human approval boundary
A fully passing deterministic evidence set can establish:
implementation_ready_for_review
It cannot by itself establish governed completion.
The evidence assessment therefore carries:
machine_validation_passed: true | false
human_completion_approval_required: true
completion_declared: false
This prevents an implementation agent from becoming both producer and final verifier of its own work.
9. Remediation semantics
Failures SHALL route to the authority that owns the defect.
Examples:
| Failure | Route |
|---|---|
| unit/contract implementation failure | zayaz-platform |
| wrong implementation repository | Hecate work-order correction or implementation remediation |
| missing canonical contract | zayaz-docs architecture resolution |
| canonical-source mismatch | regenerate/rebind HNC packet |
| unresolved human ambiguity | human decision |
| failed CI | implementation remediation |
| rejected human review | implementation remediation / governed reconsideration |
An implementation agent SHALL NOT repair a higher-authority canonical gap by inventing a local rule.
10. Requirements-to-runtime lineage
The work-order/evidence pair creates a traceable bridge:
Need
→ ImplementationPacket
→ EngineeringWorkOrder
→ implementation commit / PR
→ CI evidence
→ ImplementationEvidence
→ Hecate assessment
→ human decision
Every evidence packet retains the canonical ZAYAZ Docs commit used to authorize the work, enabling reverse provenance from runtime implementation to architectural intent.
11. Operational integration direction
HNC-1.1-G establishes the contracts and deterministic assessment logic. Execution-provider adapters may subsequently dispatch EngineeringWorkOrders to approved AI engineering environments and ingest returned evidence.
Provider-specific APIs SHALL remain adapters. The canonical EngineeringWorkOrder and ImplementationEvidence contracts SHALL remain provider-neutral.
This permits future use of multiple AI engineering systems without changing Hecate's governance semantics.
12. Constitutional invariants
- AI cannot self-certify governed completion.
- Canonical source commit is immutable across handoff and evidence return.
- Agent permissions come from the autonomy registry.
- Returned implementation must belong to the authorized repository.
- Every required blocking validation gate requires inspectable evidence.
- CI evidence is referenced, not replaced by AI prose.
- Blocking clarification prevents agent-ready implementation.
- Higher-authority gaps route upward rather than being locally invented around.
implementation_ready_for_reviewandcompletedare distinct states.- Provider-specific AI tooling is an adapter beneath the canonical HNC contracts.