Hecate Persistence and Artifact Impact Resolution

1. Purpose

HNC v1.2 extends Hecate from implementation-intent resolution into complete governed implementation-impact resolution.

HNC v1.1 answers:

What canonical requirement is being implemented, where may it be implemented, and how must implementation be validated?

HNC v1.2 additionally answers:

What concrete governed artifacts must exist or change for that requirement to become a complete implementation?

The governing principle is:

Architecture defines the required behavior. Hecate derives the implementation impact. AI implements the authorized impact. Machines verify conformance. Humans approve governed boundaries and release.

Hecate MUST NOT invent persistence, schemas, registries, rulesets, infrastructure or interfaces that cannot be justified by canonical architecture or controlled implementation policy.

2. Position in the delivery model

Human Need
    ↓
Canonical ZAYAZ Docs
    ↓
HNC v1.1 Canonical Resolution
    ↓
ImplementationPacket
    ↓
HNC v1.2 Artifact Impact Resolution
    ├── application impact
    ├── persistence impact
    ├── migration impact
    ├── schema/contract impact
    ├── registry impact
    ├── ruleset impact
    ├── event impact
    ├── infrastructure impact
    ├── integration impact
    ├── security/tenant impact
    └── test/evidence impact
    ↓
ArtifactImpactPlan
    ↓
Human approval in Jira
    ↓
EngineeringWorkOrder
    ↓
AI Engineering
    ↓
zayaz-platform
    ↓
CI / deterministic validation
    ↓
ImplementationEvidence
    ↓
Human release approval
    ↓
AWS staging / production gates

The two human boundaries remain mandatory:

1. Build authorization — approval of governed implementation intent and impact.
2. Release authorization — approval after inspectable implementation evidence.

3. ArtifactImpactPlan

ArtifactImpactPlan is the principal v1.2 output. It describes the complete machine-readable implementation footprint derived from a Need and its canonical source binding.

Conceptual envelope:

ArtifactImpactPlan
├── impact_plan_id
├── need_id
├── implementation_packet_ref
├── canonical_source_commit
├── source_scope_hash
├── implementation_target
├── application_changes[]
├── persistence_changes[]
├── migration_plans[]
├── schema_contract_changes[]
├── registry_impacts[]
├── ruleset_impacts[]
├── event_impacts[]
├── infrastructure_impacts[]
├── integration_impacts[]
├── security_impacts[]
├── validation_impacts[]
├── evidence_requirements[]
├── unresolved_impacts[]
└── derivation_lineage[]

Every material impact MUST identify the canonical requirement or controlled implementation rule that caused it.

4. Impact classes

Initial governed impact classes are:

APPLICATION
PERSISTENCE
MIGRATION
SCHEMA_CONTRACT
REGISTRY
RULESET
EVENT
INFRASTRUCTURE
INTEGRATION
SECURITY
VALIDATION
EVIDENCE

These classes describe implementation impact; they are not ZAYAZ Modules or Components.

5. Persistence impact resolution

Hecate must determine whether a canonical requirement implies:

• no persistence change;
• creation of a persistence object;
• extension of an existing persistence object;
• relationship/foreign-key change;
• uniqueness or integrity constraint;
• index/search requirement;
• effective-dated or bitemporal history;
• immutable/audit record;
• tenant isolation;
• row-level security or equivalent policy;
• retention/deletion restrictions;
• provenance/evidence linkage;
• high-volume partitioning or lifecycle strategy.

Hecate MUST distinguish semantic requirements from physical storage choices. A canonical object does not automatically imply one SQL table.

6. PersistenceChange

Conceptual contract:

PersistenceChange
├── change_id
├── change_type
├── logical_object
├── canonical_requirement_refs[]
├── storage_semantics
├── fields[]
│   ├── field_name
│   ├── semantic_definition
│   ├── logical_type
│   ├── required
│   ├── mutability
│   ├── classification
│   ├── provenance_requirement
│   └── constraints[]
├── keys[]
├── relationships[]
├── indexes[]
├── temporal_policy
├── tenant_policy
├── security_policy
├── retention_policy
├── migration_required
└── implementation_freedom[]

Every governed field MUST have a semantic definition. AI MUST NOT create unexplained persistence fields merely because they are convenient for implementation.

7. MigrationPlan

A persistence change that affects an existing deployable data store requires explicit migration analysis.

MigrationPlan
├── migration_id
├── persistence_change_refs[]
├── migration_type
├── forward_requirements[]
├── rollback_strategy
├── compatibility_strategy
├── data_backfill_required
├── backfill_strategy?
├── destructive_change
├── downtime_expectation
├── tenant_impact
├── validation_gate_ids[]
└── evidence_requirements[]

A migration is not considered complete merely because SQL executes successfully. Hecate must require evidence appropriate to compatibility, integrity, tenant isolation and rollback risk.

Destructive changes require explicit governed authorization.

8. Schema and contract impact

Hecate must identify impacts to:

• JSON Schema;
• API request/response contracts;
• event envelopes;
• persistence contracts;
• domain object contracts;
• integration contracts;
• versioned interoperability payloads.

A persistence field used across a service boundary must be traceable to the applicable contract rather than silently leaking through an ORM or serialization layer.

Compatibility impact must be classified before implementation.

9. Registry impact

Controlled vocabularies belong in governed registries rather than scattered literals.

Hecate must detect when implementation requires:

• reuse of an existing registry value;
• addition of a governed registry value;
• creation of a new registry;
• deprecation or supersession of a value;
• registry/schema synchronization;
• compatibility review.

An engineering agent MUST NOT invent authoritative enum values where a controlled registry exists.

10. Ruleset impact

Rulesets represent governed decision logic that must remain distinguishable from application plumbing.

Examples include:

• EPU identity-change outcomes;
• supplier requirement applicability;
• TrustGate thresholds;
• comparability rules;
• disclosure eligibility;
• evidence expiry;
• acquisition trigger policy.

RulesetImpact must identify rule ownership, versioning, inputs, outputs, effective period, precedence, test scenarios and approval requirements.

Application code may execute a ruleset; it must not silently redefine the ruleset.

11. Event impact

Hecate must determine whether a requirement creates or changes a domain/integration event.

Event impact includes:

• event type;
• producer;
• consumers;
• payload contract;
• ordering/idempotency requirements;
• replay requirements;
• compatibility/versioning;
• retention;
• provenance/correlation identifiers;
• failure/dead-letter semantics where applicable.

12. Infrastructure impact

Infrastructure impacts may include:

• database/storage resource;
• queue/topic/event bus;
• object-storage location;
• search/index resource;
• cache;
• scheduled process;
• secret/configuration;
• IAM policy;
• observability resource;
• network/security boundary;
• deployment/migration job.

Hecate resolves required capability, not arbitrary cloud topology. AWS-specific implementation remains subordinate to canonical platform architecture and infrastructure policy.

13. Integration impact

Integration impact must identify:

• external/internal system boundary;
• interface/adapter;
• authoritative source direction;
• contract/version;
• authentication/authorization requirement;
• retry/idempotency semantics;
• rate/volume assumptions;
• error and reconciliation behavior;
• provenance requirements.

14. Security and tenancy impact

Every persistence or service impact must be evaluated for:

• tenant isolation;
• white-label boundary;
• authorization scope;
• data classification;
• graph-discovery policy where applicable;
• supplier confidentiality;
• auditability;
• evidence access;
• retention/deletion constraints.

Security impact is not optional metadata added after implementation.

15. Validation impact

HNC v1.2 extends the v1.1 ValidationPlan based on the resolved artifact footprint.

Representative derived gates include:

schema
registry
static
unit
negative
property
contract
compatibility
integration
workflow
replay
security
migration
rollback
tenant_isolation
infrastructure
staging

A migration impact should automatically cause migration/compatibility/rollback gates where policy requires them. A registry impact should cause registry-integrity validation. A tenant-bearing persistence impact should cause tenant-isolation validation.

16. Evidence impact

Every derived gate must map to inspectable evidence expectations.

Examples:

• migration test report;
• schema validation report;
• contract compatibility report;
• registry integrity result;
• tenant-isolation test result;
• rollback rehearsal result;
• infrastructure plan/apply evidence;
• integration test evidence;
• CI run reference;
• governed human approval/waiver.

AI prose is never a substitute for machine-verifiable evidence where deterministic evidence is available.

17. Derivation authority

Each impact item must carry a derivation classification:

CANONICAL_REQUIRED
POLICY_REQUIRED
DERIVED_NECESSARY
IMPLEMENTATION_OPTION
UNRESOLVED

Meaning:

• CANONICAL_REQUIRED — explicitly required by canonical ZAYAZ Docs/contracts.
• POLICY_REQUIRED — required by controlled platform/engineering policy.
• DERIVED_NECESSARY — logically necessary to satisfy an explicit requirement.
• IMPLEMENTATION_OPTION — permitted implementation choice within agent autonomy.
• UNRESOLVED — insufficient canonical authority; must not be invented by the agent.

UNRESOLVED impacts route to architecture clarification before autonomous implementation.

18. No architecture invention

Hecate MUST fail closed when a required implementation decision would establish new architecture without authority.

Examples:

• choosing a new canonical database technology;
• creating a new top-level ZAYAZ Module;
• inventing a new authoritative identity class;
• introducing an ungoverned ruleset vocabulary;
• changing an API/event contract without compatibility policy;
• weakening tenant/security requirements;
• creating destructive migrations without authorization.

Such cases route to the appropriate human/canonical remediation layer.

19. Requirements-to-runtime provenance

The intended lineage is:

Canonical requirement
    ↓
Need
    ↓
ImplementationPacket
    ↓
ArtifactImpactPlan
    ↓
Persistence / schema / registry / ruleset / event / infra impact
    ↓
EngineeringWorkOrder
    ↓
source files + migrations + IaC + tests
    ↓
CI / validation evidence
    ↓
ImplementationEvidence
    ↓
deployment artifact
    ↓
AWS runtime resource/version

A future Pergamum Pulse traversal should be able to preserve both ZAYAZ Module and Component lineage across this chain.

20. EPU reference case

The first v1.2 reference implementation should use the EPU Product Identity / Alias Registry domain.

Canonical requirements already establish that aliases are:

• linked to EPU;
• identifier-type and identifier-value bearing;
• source/issuer scoped;
• effective-dated;
• authority/provenance bearing;
• conflict-detectable;
• not equivalent to EPU identity.

Hecate v1.2 should derive the implementation footprint without assuming that the conceptual ExternalAlias object maps one-to-one to a physical SQL table.

The reference test should prove:

EPU canonical requirement
    ↓
ArtifactImpactPlan
    ↓
PersistenceChange
    ↓
MigrationPlan (when required)
    ↓
contract / registry impacts
    ↓
validation gates
    ↓
EngineeringWorkOrder
    ↓
ImplementationEvidence

21. Planned HNC v1.2 increments

HNC-1.2-A — Canonical specification

This document. Defines impact classes, authority boundaries and the reference flow.

HNC-1.2-B — Payload contracts

Introduce machine-readable schemas for at least:

• ArtifactImpactPlan;
• PersistenceChange;
• MigrationPlan;
• RulesetImpact;
• InfrastructureImpact.

HNC-1.2-C — Controlled registries

Introduce governed vocabularies for artifact-impact classes, persistence changes, migration types, derivation authority and implementation artifact types.

HNC-1.2-D — Validators and fixtures

Validate structural and cross-artifact invariants, including negative cases.

HNC-1.2-E — Impact Resolver

Extend Hecate with deterministic impact derivation from canonical source, controlled registries and platform policy.

HNC-1.2-F — Engineering handoff extension

Add resolved artifact requirements to EngineeringWorkOrder without permitting the agent to expand its own authority.

HNC-1.2-G — EPU persistence golden path

Prove the Product Identity / Alias Registry reference flow end-to-end.

HNC-1.2-H — Operational staging bridge preparation

Prepare the governed Jira-approved → AI engineering → zayaz-platform → CI evidence path for a live staging smoke test.

22. Constitutional invariants

1. Canonical architecture remains authoritative over implementation convenience.
2. Hecate derives implementation impact; it does not silently invent architecture.
3. Every material impact must identify its authority and derivation lineage.
4. Conceptual objects do not automatically imply physical tables.
5. Persistence fields require semantic definitions.
6. Destructive migrations require explicit authorization.
7. Controlled vocabularies belong in registries, not scattered application literals.
8. Governed rulesets remain distinct from application plumbing.
9. Schema/event/API changes require compatibility analysis.
10. Tenant isolation and security are first-class impact dimensions.
11. Derived impacts extend validation and evidence requirements automatically.
12. AI may choose only implementation options permitted by the approved impact plan and autonomy policy.
13. AI may implement and report evidence but may not self-certify governed completion.
14. Build approval and release approval remain separate human/governance boundaries.
15. Requirements-to-runtime lineage must remain reconstructable.