Skip to main content

Hecate Operational Staging Bridge

1. Purpose

HNC-1.2-H prepares the first governed operational bridge between deterministic Hecate contracts and a future live staging smoke test.

The bridge does not authorize deployment. It converts an already approved Jira implementation decision into a machine-verifiable execution envelope that may be consumed by controlled engineering automation in viroway-ltd/zayaz-platform.

Build authorization permits implementation work. Release authorization permits release. The staging bridge must never collapse these boundaries.

2. Operational chain

Canonical ZAYAZ Docs

Need + ImplementationPacket

ArtifactImpactPlan

Jira build authorization

EngineeringWorkOrder

StagingBridgeEnvelope

zayaz-platform controlled engineering branch / PR

CI + required validation gates

ImplementationEvidence

Hecate deterministic evidence assessment

IMPLEMENTATION_READY_FOR_REVIEW

Human release authorization

separate AWS staging/deployment gate

HNC-1.2-H prepares through the CI/evidence boundary. Live AWS staging remains a subsequent governed capability.

3. StagingBridgeEnvelope

The canonical machine contract is schemas/hnc/payloads/staging-bridge-envelope.schema.v1.json.

The envelope binds:

  • Need identity;
  • Jira issue identity;
  • exact canonical source commit;
  • EngineeringWorkOrder identity and deterministic hash;
  • ArtifactImpactPlan identity and deterministic hash;
  • explicit human build authorization;
  • the authorized zayaz-platform repository and base ref;
  • required validation gates;
  • required evidence types;
  • an explicit closed release boundary.

The envelope is deterministic for the same governed inputs. generated_at is observational metadata and does not change bridge identity.

4. Build authorization

A bridge may be issued only when Jira contains an explicit governed build authorization.

Minimum authorization evidence:

BuildAuthorization
├── decision = approved
├── actor_ref
├── decided_at
└── source_ref

The source_ref must make the approval auditable back to Jira or another future approved governance source.

A Jira issue merely existing, being assigned, or being in a generic workflow state is not sufficient unless controlled Jira policy explicitly maps that state to build authorization.

5. Engineering target boundary

For the first reference path, the only authorized runtime target is:

viroway-ltd/zayaz-platform

The bridge may authorize preparation of an engineering branch or pull request and execution of deterministic validation. It does not authorize direct writes to main, PR merge, deployment, infrastructure mutation, or AWS credentials.

The engineering agent remains constrained by the EngineeringWorkOrder, ArtifactImpactPlan, allowed paths, forbidden changes, autonomy level and required output/evidence contracts.

6. Release boundary

Every HNC-1.2 staging bridge is emitted with:

release_authorization_required: true
release_authorization_present: false
merge_allowed: false
deployment_allowed: false

These values are constitutional for the preparation bridge. A later release/deployment contract may consume approved evidence and record a separate human release decision; it must not mutate this historical bridge to imply that release authority existed earlier.

7. CI evidence preparation

The operational target should be able to prove, at minimum:

  1. the bridge envelope is structurally valid;
  2. work-order and impact-plan hashes match the approved inputs;
  3. the canonical source commit is preserved;
  4. implementation occurs in the authorized repository;
  5. all required validation gates execute or return a governed waiver;
  6. required evidence types are collected;
  7. CI evidence can be converted into ImplementationEvidence;
  8. deterministic Hecate assessment remains separate from human completion/release approval.

8. Passive platform intake

The first zayaz-platform workflow is intentionally passive and manually dispatchable. It may validate an encoded StagingBridgeEnvelope, run repository tests, and publish an evidence-preparation artifact.

It MUST NOT:

  • create or merge a PR automatically;
  • push implementation changes;
  • deploy to AWS;
  • assume cloud credentials;
  • set release_authorization_present to true;
  • claim governance completion.

This establishes the operational seam before introducing live AI engineering or deployment automation.

9. Failure semantics

The bridge fails closed when:

  • build authorization is missing or not approved;
  • unresolved architecture remains;
  • Need, ImplementationPacket, canonical commit or ArtifactImpactPlan lineage mismatches;
  • ArtifactImpactPlan hash differs from the approved EngineeringWorkOrder;
  • target repository differs from the authorized implementation target;
  • the work order is not v1.2 impact-bound;
  • required validation/evidence obligations cannot be represented.

A failed bridge routes to remediation; it does not weaken validation requirements.

10. EPU staging reference

The first live smoke candidate remains EPU ExternalAlias persistence because HNC-1.2-G already proves the deterministic chain for:

  • effective-dated persistence;
  • source/authority-scoped alias semantics;
  • tenant and supplier-confidentiality requirements;
  • governed migration;
  • alias-conflict ruleset reuse;
  • persistence capability without arbitrary database selection.

The live smoke test should therefore exercise the same governed Need and impact lineage rather than invent a separate staging-only architecture.

11. Acceptance criteria for HNC-1.2-H

HNC-1.2-H is complete when deterministic tests prove:

  • stable bridge identity for identical governed inputs;
  • explicit build authorization is mandatory;
  • unresolved architecture blocks bridge creation;
  • canonical/impact tampering blocks bridge creation;
  • wrong runtime repository blocks bridge creation;
  • release authority remains false in every preparation envelope;
  • the passive platform workflow cannot merge or deploy.

A successful H does not mean AWS staging is live. It means the governance and machine-contract seam is ready for a controlled live staging smoke test.

GitHub RepoRequest for Change (RFC)