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-platformrepository 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:
- the bridge envelope is structurally valid;
- work-order and impact-plan hashes match the approved inputs;
- the canonical source commit is preserved;
- implementation occurs in the authorized repository;
- all required validation gates execute or return a governed waiver;
- required evidence types are collected;
- CI evidence can be converted into
ImplementationEvidence; - 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_presentto 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.