Skip to main content

Hecate EPU Golden-Path Reference

1. Purpose​

HNC-1.1-H establishes the first canonical end-to-end reference acceptance test for the governed ZAYAZ delivery model.

The reference scenario starts from the canonical EPU Product Identity Resolver scope and proves that implementation authority, source provenance, Jira work projection, AI engineering constraints, validation requirements and implementation evidence remain linked across the delivery chain.

The reference is deliberately deterministic. It is not a claim that pytest performs live Jira, GitHub Actions or AWS deployment operations.

2. Reference chain​

Human Need
    ↓
ZAYAZ Docs — EPU Product Identity Resolver
    ↓
Hecate deterministic resolution
    ├── ImplementationPacket
    ├── ValidationPlan
    └── AgentContextPack
    ↓
Jira governed projection
    ↓
EngineeringWorkOrder
    ↓
AI engineering implementation boundary
    ↓
ImplementationEvidence
    ↓
Hecate deterministic evidence assessment
    ↓
IMPLEMENTATION_READY_FOR_REVIEW
    ↓
Human completion approval remains required

The canonical source section is:

EPU-CANONICAL-OBJECT-SERVICE-MODEL
§5.3 Product Identity Resolver

That scope requires the resolver to consume source-product candidates, perform deterministic alias and characteristic matching, constrain probabilistic or AI-assisted comparison to governed use, produce confidence/explainability, route ambiguity to human review and preserve complete decision lineage.

3. Golden-path invariants​

The automated reference test must prove all of the following.

3.1 Human intent to canonical truth​

  • one HNC Need identity is preserved;
  • the exact EPU canonical document and section resolve deterministically;
  • an exact canonical Git commit is bound;
  • a SHA-256 source-scope hash is generated;
  • scope invention is prohibited;
  • ambiguity requires clarification rather than agent invention.

3.2 Canonical truth to Jira work​

  • Jira summary derives from resolved implementation intent;
  • existing Need ID, Spec ID and Spec URL semantics are preserved;
  • hnc.delivery.meta binds Jira work to canonical commit and scope hash;
  • the canonical source is represented as a governed web link;
  • canonical URLs are not injected into generated human instruction prose.

3.3 Jira work to AI engineering authority​

  • the implementation target resolves to viroway-ltd/zayaz-platform for runtime feature work;
  • the EngineeringWorkOrder carries the exact canonical commit;
  • required validation gates are identical to the resolved ValidationPlan;
  • autonomy permissions come from the controlled HNC autonomy registry;
  • AI self-certification is forbidden;
  • merge/deployment authority is not implied by implementation authority.

3.4 Implementation evidence to governed review readiness​

  • returned evidence references the same Need and ImplementationPacket;
  • implementation occurs only in the authorized repository;
  • canonical source commit provenance is unchanged;
  • every required validation gate has returned evidence;
  • deterministic evidence assessment passes before review readiness;
  • machine validation does not declare governance completion;
  • human completion approval remains required.

4. Negative-path requirements​

The reference test must also prove fail-closed behavior.

At minimum:

  1. tampering with the canonical source commit must produce remediation_required;
  2. returning implementation evidence from a repository outside the authorized target must produce remediation_required.

These failures must set machine_validation_passed to false and expose a blocking reason.

5. Test implementation​

The executable reference is:

tools/viroway-tools/tests/test_hnc_epu_golden_path.py

The test uses the real canonical EPU MDX source and current checked-out Git commit. Jira is represented by the deterministic HNC Jira projection contract. AI implementation and CI are represented by a schema-valid ImplementationEvidence envelope.

This separation is intentional: contract tests must be reproducible without external service credentials or mutable infrastructure state.

6. What HNC-1.1-H proves​

A successful golden-path test demonstrates that the six-layer operating model is internally coherent through the implementation-evidence boundary:

Humans define intent. ZAYAZ Docs defines truth. Jira defines work. AI builds and verifies. ZAYAZ Platform contains the implementation. AWS executes it.

HNC-1.1-H proves the first five layers and the evidence contract that precedes runtime/deployment verification. It does not claim live AWS execution.

7. What remains outside this test​

The following require staging/integration validation rather than deterministic contract tests:

  • live Hecate modal submission;
  • live Jira issue creation/update and issue-property persistence;
  • live AI engineering agent invocation;
  • real zayaz-platform PR/commit creation;
  • real GitHub Actions evidence collection;
  • AWS deployment and runtime telemetry;
  • requirements-to-runtime correlation against deployed infrastructure.

Those capabilities should be proven through a separate governed staging smoke test after the deterministic golden path is stable.

8. Acceptance state​

HNC-1.1-H is considered validated only when the complete viroway-tools test suite passes with the EPU golden-path tests included.

The expected successful terminal state of the positive reference is:

status: implementation_ready_for_review
machine_validation_passed: true
human_completion_approval_required: true
completion_declared: false

This is intentionally not completed. Completion remains a governed human decision after machine-verifiable evidence has passed.

GitHub RepoRequest for Change (RFC)