Skip to main content

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_test may modify and test but may not open a PR;
  • open_pr may open a PR but may not merge;
  • merge_eligible still requires all blocking gates and required approvals before merge;
  • deployment_eligible does 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:

  1. schema validity;
  2. Need identity;
  3. Implementation Packet reference;
  4. canonical source commit;
  5. authorized implementation repository;
  6. evidence for every required validation gate;
  7. failed blocking gates;
  8. CI run references;
  9. unresolved clarification state;
  10. autonomy state;
  11. 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:

FailureRoute
unit/contract implementation failurezayaz-platform
wrong implementation repositoryHecate work-order correction or implementation remediation
missing canonical contractzayaz-docs architecture resolution
canonical-source mismatchregenerate/rebind HNC packet
unresolved human ambiguityhuman decision
failed CIimplementation remediation
rejected human reviewimplementation 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

  1. AI cannot self-certify governed completion.
  2. Canonical source commit is immutable across handoff and evidence return.
  3. Agent permissions come from the autonomy registry.
  4. Returned implementation must belong to the authorized repository.
  5. Every required blocking validation gate requires inspectable evidence.
  6. CI evidence is referenced, not replaced by AI prose.
  7. Blocking clarification prevents agent-ready implementation.
  8. Higher-authority gaps route upward rather than being locally invented around.
  9. implementation_ready_for_review and completed are distinct states.
  10. Provider-specific AI tooling is an adapter beneath the canonical HNC contracts.


GitHub RepoRequest for Change (RFC)