Pergamum Pulse HECATE Knowledge Conformance Profile

Version 0.1 — Normative Knowledge Validation and Conformance Contract

This Profile defines how HECATE validates Pergamum Pulse knowledge objects, relationships, rights, assertions, mappings, retrieval artefacts, Change Candidates, projections and historical records.

It governs:

Conformance Profiles;
Rule Sets;
Validation Rules;
Validation Requests;
Evidence Snapshots;
Validation Executions;
Findings;
severity;
confidence;
gates;
Conformance Receipts;
exception treatment;
waiver treatment;
remediation;
revalidation;
deterministic execution;
cross-object validation;
graph validation;
rights validation;
semantic-structure validation;
temporal validation;
tenant and white-label isolation;
retrieval and AI-processing validation;
Candidate and projection validation;
Publication readiness validation;
certification-boundary validation;
historical replay;
operational assurance;
security;
audit;
conformance.

The governing principles are:

HECATE SHALL validate objective conformance against approved Rules, Profiles, schemas, invariants and evidence snapshots.

HECATE SHALL NOT create truth, authority, rights, legal interpretation, semantic meaning, equivalence, certification, Publication approval or Runtime activation.

A passing HECATE receipt proves only that the evaluated object satisfied the identified Rules under the identified Profile, versions, evidence and execution context.

A failed HECATE receipt SHALL identify reproducible Findings without silently repairing, suppressing or reinterpreting the evaluated object.

HECATE SHALL validate the object that exists, not the object the evaluator expected or intended to exist.

Every material validation SHALL preserve the exact object versions, Rule versions, Profile version, schema versions, evidence snapshot, execution environment, Findings and receipt digest.

Rules SHALL be deterministic where the criterion is objective. Non-deterministic or model-assisted checks SHALL be explicitly classified and SHALL NOT masquerade as deterministic validation.

HECATE SHALL preserve the distinction between structural validity, semantic consistency, governance completeness, rights eligibility, operational eligibility and authority.

No Finding SHALL be ignored merely because another Rule passes, a model assigns high confidence or an operator prefers release.

Exceptions and waivers SHALL be explicit, authority-bearing, scoped, time-bound, reviewable and historically reconstructable.

Tenant, white-label, confidentiality and rights boundaries SHALL apply to validation inputs, temporary workspaces, logs, evidence, Findings, receipts and exports.

Historical validation SHALL reconstruct what conformed under the Rules and versions in force at the relevant time without silently applying current interpretations retroactively.

1. Scope

This Profile applies to HECATE validation of:

Source Series;
Source Objects;
Source Captures;
Rights Records;
Knowledge Documents;
Knowledge Sections;
Source Fragments;
Knowledge Assertions;
Knowledge Entities;
Knowledge Bundles;
Citation Objects;
Mapping Objects;
Crosswalk Sets;
Change Candidates;
Change Decisions;
Projection Manifests;
Generated Artefacts;
Retrieval Eligibility Records;
Knowledge Chunks;
Embedding Records;
Retrieval Indexes;
Context Packages;
Prompt Profiles;
Model Profiles;
AI Processing Tasks;
AI Inference Records;
Grounding Records;
Publications;
historical records;
tenant overlays;
white-label overlays;
Registries;
schemas;
validation Rules;
conformance evidence.

It applies to:

local validation;
build-time validation;
continuous integration;
Registry admission;
graph admission;
projection eligibility;
release readiness;
activation admission;
Publication readiness;
tenant migration;
white-label release;
assurance;
audit;
historical replay;
incident investigation.

This Profile does not itself authorise:

legal conclusions;
rights grants;
semantic adoption;
Change Decisions;
constitutional evolution;
Public Publication;
certification decisions;
Runtime activation;
exception approval;
risk acceptance.

2. Normative Language

The terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY and MAY NOT are normative.

Where this Profile conflicts with PP-KDMF, the framework prevails.

Where a target specification, constitutional framework, approved ADR, tenant contract, white-label agreement or security policy is stricter, the stricter requirement prevails.

No implementation Profile SHALL weaken:

object identity;
evidence;
rights;
authority separation;
temporal validity;
tenant isolation;
white-label isolation;
provenance;
deterministic replay;
Finding visibility;
exception traceability;
activation separation.

3. HECATE Role and Authority Boundary

HECATE is a validation Component.

HECATE MAY:

validate schemas;
validate required metadata;
validate object references;
validate identifiers;
validate lifecycle transitions;
validate bitemporal constraints;
validate rights-state completeness;
validate tenant and white-label scope;
validate graph integrity;
validate Mapping Object structure;
validate assertion structure;
validate Candidate and Decision relationships;
validate projection inputs and artefacts;
validate digests;
validate signatures;
execute deterministic test fixtures;
produce Findings;
produce Conformance Receipts;
support assurance and audit.

HECATE SHALL NOT:

decide what a law means;
decide whether a disputed interpretation is correct;
determine copyright ownership;
grant a licence;
waive attribution;
decide fair use or fair dealing;
invent a Knowledge Assertion;
approve a semantic mapping;
approve a Change Candidate;
issue a Change Decision;
create constitutional authority;
create certification status;
approve public claims;
activate Runtime state;
conceal failed validation;
silently mutate evaluated objects.

3.1. Validation Versus Authority

The following SHALL remain distinct:

Object exists
      ↓
Object is structurally valid
      ↓
Object is governance-complete
      ↓
Object passes HECATE Rules
      ↓
Object may be eligible for review or admission
      ↓
Authorised Decision
      ↓
Projection or Publication
      ↓
Separate activation or release

A pass at one stage SHALL NOT imply passage or authority at a later stage.

3.2. Rule Authority

A Rule's authority derives from its governing specification, approved Profile or invariant.

HECATE does not create Rule authority.

3.3. Finding Authority

A Finding records observed non-conformance against an identified Rule.

A Finding SHALL not be represented as a legal ruling or semantic judgement unless the Rule itself encodes an approved objective criterion.

3.4. Receipt Boundary

A receipt SHALL identify exactly what it proves and what it does not prove.

4. Conformance Architecture

The canonical validation path is:

Validation Request
        │
        ▼
Target and Scope Resolution
        │
        ▼
Evidence Snapshot
        │
        ▼
Conformance Profile Resolution
        │
        ▼
Rule Set Resolution
        │
        ▼
Execution Plan
        │
        ▼
Deterministic and Declared Assisted Checks
        │
        ▼
Findings
        │
        ▼
Gate Evaluation
        │
        ▼
Conformance Receipt
        │
        ├── Pass
        ├── Pass with Warnings
        ├── Fail
        ├── Blocked
        └── Unable to Determine
        │
        ▼
Remediation / Exception / Revalidation

The following SHALL remain separate:

Rule definition;
Rule Set;
Conformance Profile;
Validation Request;
Evidence Snapshot;
Execution;
Finding;
gate outcome;
receipt;
exception;
waiver;
remediation;
revalidation;
authoritative Decision.

5. Canonical HECATE Objects

Object	Prefix	Purpose
HECATE Conformance Profile	`PP-HCP-`	Defines target classes, Rule Sets, gates and receipt policy
HECATE Rule Set	`PP-HRS-`	Groups approved Validation Rules
HECATE Validation Rule	`PP-HRL-`	Defines one objective or declared assisted criterion
HECATE Validation Request	`PP-HRQ-`	Requests validation of identified targets
HECATE Evidence Snapshot	`PP-HES-`	Freezes evaluated objects and relevant dependencies
HECATE Execution Plan	`PP-HEP-`	Resolves ordered Rules, dependencies and execution policy
HECATE Validation Execution	`PP-HEX-`	Records one execution
Finding	`PP-FND-`	Records one observed conformance result or defect
Conformance Receipt	`PP-RCPT-`	Records signed or digest-verifiable validation outcome
HECATE Exception Decision	`PP-HED-`	Records approved exception or waiver treatment
HECATE Remediation Plan	`PP-HRP-`	Records correction and revalidation actions
HECATE Attestation	`PP-HAT-`	Records human or organisational attestation
HECATE Baseline	`PP-HBL-`	Defines a governed conformance baseline
HECATE Historical Record	`PP-HHR-`	Preserves historical validation state
HECATE Incident	`PP-HIN-`	Records validator, Rule, execution or receipt incident

6. HECATE Conformance Profile

A Conformance Profile defines what shall be validated for a declared purpose.

hecate_conformance_profile:
  profile_id: PP-HCP-000001
  profile_version: 1.0.0
  canonical_name: Pergamum Pulse Knowledge Assertion Admission

  purpose: assertion_registry_admission

  target_classes:
    - knowledge_assertion

  rule_sets:
    - PP-HRS-000001@1.0.0
    - PP-HRS-000002@2.1.0

  gates:
    admission:
      blocking_severities:
        - critical
        - high
      warning_threshold: 10

  receipt_policy:
    signature_required: true
    expiry: P90D

  provenance: {}

6.1. Required Profile Fields

Every Conformance Profile SHALL identify:

Profile identity;
Profile version;
canonical name;
purpose;
target classes;
included Rule Sets;
excluded Rule Sets;
Rule precedence;
gate policy;
severity policy;
exception policy;
evidence requirements;
receipt policy;
expiry policy;
tenant and white-label scope;
security classification;
owning Module;
owning Component;
approval authority;
provenance.

6.2. Profile Purpose

Purposes MAY include:

structural validation;
source admission;
Rights Record admission;
document admission;
assertion admission;
Mapping Object admission;
graph admission;
retrieval eligibility;
embedding admission;
Candidate eligibility;
projection eligibility;
release readiness;
activation admission;
Publication readiness;
certification support;
assurance;
audit;
historical replay.

6.3. Profile Versioning

A material change in:

included Rules;
gate thresholds;
severity;
exception policy;
evidence requirements;
receipt expiry;
scope;
target classes

SHALL create a new Profile version.

6.4. Profile Immutability

An executed Profile version SHALL remain immutable.

6.5. Profile Non-Authority

A Conformance Profile SHALL not grant authority beyond the governing frameworks and target governance.

7. HECATE Rule Set

A Rule Set groups Rules for a declared domain.

hecate_rule_set:
  rule_set_id: PP-HRS-000001
  rule_set_version: 1.0.0
  canonical_name: Knowledge Assertion Structural Rules

  domain: knowledge_assertion
  rules:
    - PP-HRL-000001@1.0.0
    - PP-HRL-000002@1.0.0

  execution:
    ordering: dependency_order
    fail_fast: false

  provenance: {}

7.1. Required Rule Set Fields

Every Rule Set SHALL identify:

Rule Set identity;
version;
canonical name;
domain;
Rules;
Rule order or dependency policy;
fail-fast policy;
parallelisation policy;
severity overrides where authorised;
applicability;
lifecycle;
owner;
approval;
provenance.

7.2. Rule Set Classes

Classes MAY include:

identity;
metadata;
schema;
provenance;
rights;
authority;
lifecycle;
temporal;
tenant;
white-label;
graph;
assertion;
mapping;
retrieval;
AI processing;
Candidate;
projection;
Publication;
certification-boundary;
security;
historical.

7.3. Rule Set Composition

Rule Sets MAY include other Rule Sets only where:

dependencies are explicit;
cycles are prohibited;
version pinning is preserved;
severity conflicts are resolved;
provenance is complete.

7.4. Rule Set Drift

A changed Rule Set SHALL trigger affected-Profile and affected-receipt analysis.

8. HECATE Validation Rule

A Validation Rule defines one conformance criterion.

hecate_validation_rule:
  rule_id: PP-HRL-000001
  rule_version: 1.0.0
  canonical_name: Knowledge Assertion identifier prefix

  rule_class: deterministic
  target_class: knowledge_assertion

  criterion:
    expression_language: cel
    expression: "target.assertion_id.startsWith('PP-KA-')"

  outcome:
    failure_severity: high
    finding_code: PP.HKCP.ASSERTION.INVALID_PREFIX

  source_authority:
    specification_id: PP-KAS
    clause: "5.1"

  provenance: {}

8.1. Required Rule Fields

Every Rule SHALL identify:

Rule identity;
Rule version;
canonical name;
definition;
Rule class;
target class;
criterion;
input fields;
expected result;
Finding code;
failure severity;
applicability;
source authority;
implementation;
test fixtures;
lifecycle;
owner;
approval;
provenance.

8.2. Rule Classes

Rule classes MAY include:

deterministic;
deterministic with external Registry lookup;
deterministic with temporal lookup;
deterministic graph query;
test-fixture execution;
statistical;
heuristic;
model-assisted;
human-attested;
composite;
informational.

8.3. Objective Criterion

A deterministic Rule SHALL use an objectively reproducible criterion.

8.4. Assisted Criterion

A statistical, heuristic or model-assisted Rule SHALL disclose:

method;
model or algorithm;
version;
thresholds;
calibration;
false-positive risk;
false-negative risk;
review requirement;
inability to create authority.

8.5. Rule Source Authority

Every Rule SHALL link to the specification, framework, ADR, Registry invariant, schema or approved policy that authorises it.

8.6. Rule Non-Invention

A Rule SHALL not encode new semantic or legal policy without an approved governing source.

8.7. Rule Versioning

A changed criterion, severity, applicability, implementation or expected result SHALL create a new Rule version.

8.8. Rule Immutability

A Rule version used in a completed receipt SHALL remain immutable.

9. Rule Applicability

Every Rule SHALL define when it applies.

Applicability dimensions MAY include:

object class;
object subtype;
lifecycle state;
Profile purpose;
jurisdiction;
framework;
Module;
Component;
Extension;
tenant;
white-label operator;
security classification;
rights state;
valid time;
transaction time;
target environment;
Publication class;
Runtime profile.

applicability:
  target_classes:
    - knowledge_assertion
  lifecycle_states:
    - proposed
    - approved
  knowledge_scope:
    - global_canonical
  tenant_scope:
    mode: any
  effective_from: 2026-08-04
  effective_to: null

9.1. Non-Applicable Rule

A Rule determined not applicable SHALL produce an explicit not_applicable result rather than a pass.

9.2. Unable to Determine

Where applicability cannot be determined, the Rule SHALL return unable_to_determine and SHALL not silently pass.

9.3. Applicability Evidence

Material applicability decisions SHALL preserve the evaluated fields and lookup versions.

9.4. Scope Generalisation Prohibition

A Rule valid for one target class, tenant, jurisdiction or lifecycle state SHALL not be generalised without an approved Profile update.

10. Rule Dependency and Ordering

Rules MAY depend on:

prior Rules;
schemas;
Registries;
graph snapshots;
Rights Records;
tenant policy;
security policy;
temporal state;
external evidence.

10.1. Dependency Declaration

Every dependency SHALL identify:

dependency object;
version;
required state;
failure behaviour;
cache policy;
provenance.

10.2. Dependency Graph

Rule dependencies SHALL form an acyclic directed graph.

10.3. Blocking Dependency

A missing or invalid blocking dependency SHALL produce blocked, not passed.

10.4. Optional Dependency

An optional dependency SHALL identify degraded behaviour and confidence impact.

10.5. Rule Ordering

Execution order SHALL respect dependencies and declared sequencing.

10.6. Fail-Fast

Fail-fast MAY be used only where:

omitted Rules are reported as not executed;
the receipt remains complete about execution state;
no required high-severity Rule is concealed;
policy permits early termination.

11. Rule Expression and Implementation

A Rule MAY be expressed using:

JSON Schema;
JSONPath;
JSON Pointer;
XPath;
SHACL;
SPARQL;
CEL;
Rego;
SQL;
graph query;
typed code;
deterministic validator;
test fixture;
approved model-assisted classifier.

11.1. Expression Language

The expression language and version SHALL be pinned.

11.2. Implementation Digest

Executable implementations SHALL preserve a digest or source revision.

11.3. Sandboxing

Rule execution SHOULD occur in a least-privileged sandbox.

11.4. Side Effects

Validation Rules SHALL be side-effect free unless a separate approved workflow explicitly permits evidence acquisition.

11.5. External Calls

External calls SHALL be:

declared;
rights-permitted;
security-approved;
time-bounded;
retry-controlled;
cached according to policy;
preserved in provenance.

11.6. Non-Deterministic Data Source

A mutable external data source SHALL be snapshotted or version-pinned for historically assured validation.

11.7. Secret Handling

Rules SHALL not embed secrets.

12. Rule Test Fixtures

Every material Rule SHOULD include:

positive fixture;
negative fixture;
boundary fixture;
not-applicable fixture;
missing-input fixture;
invalid-type fixture;
historical fixture where relevant;
tenant-isolation fixture where relevant;
rights-restricted fixture where relevant.

12.1. Fixture Identity

Fixtures SHALL possess stable identities and versions.

12.2. Expected Outcome

Every fixture SHALL identify the expected:

Rule result;
Finding code;
severity;
evidence path;
gate impact.

12.3. Fixture Regression

Rule implementation changes SHALL pass all applicable fixtures.

12.4. Golden Receipt

Critical Rule Sets SHOULD maintain Golden Receipts for deterministic regression.

12.5. Fixture Rights

Fixture content SHALL preserve rights and privacy.

13. Severity Model

Every failed or cautionary Rule SHALL produce a severity.

Core severities are:

informational;
low;
moderate;
high;
critical;
constitutional.

13.1. Informational

Informational Findings describe non-blocking observations.

13.2. Low

Low Findings identify minor defects with limited downstream risk.

13.3. Moderate

Moderate Findings identify material quality or governance weakness requiring treatment.

13.4. High

High Findings identify defects that normally block admission, projection, release or activation.

13.5. Critical

Critical Findings identify immediate security, rights, tenant-isolation, data-integrity, legal or operational risk.

13.6. Constitutional

Constitutional Findings identify conflict with protected constitutional meaning, authority boundaries or invariants.

13.7. Severity Authority

Severity SHALL originate from the approved Rule or authorised Profile override.

13.8. Dynamic Escalation

A Profile MAY escalate severity based on:

target environment;
object lifecycle;
tenant count;
public exposure;
certification reliance;
Runtime impact;
repeated occurrence.

Dynamic escalation SHALL be deterministic and auditable.

13.9. Severity Reduction

Severity SHALL not be reduced by the validator at execution time without an approved Rule or Profile version.

14. Finding Codes

Every Finding SHALL possess a stable code.

Recommended format:

PP.HKCP.<DOMAIN>.<RULE_NAME>

Examples:

PP.HKCP.IDENTITY.INVALID_PREFIX
PP.HKCP.RIGHTS.MISSING_PERMISSION_BASIS
PP.HKCP.ASSERTION.MISSING_SOURCE_FRAGMENT
PP.HKCP.MAPPING.UNSUPPORTED_EQUIVALENCE
PP.HKCP.TENANT.CROSS_SCOPE_REFERENCE
PP.HKCP.PROJECTION.MISSING_CHANGE_DECISION

14.1. Code Registry

Finding codes SHALL be Registry-governed.

The Registry SHALL preserve:

code;
definition;
Rule;
severity;
remediation guidance;
lifecycle;
replacement code;
provenance.

14.2. Code Stability

A Finding code SHALL not be reused for a different defect.

14.3. Deprecated Code

Deprecated codes SHALL remain resolvable for historical receipts.

15. Validation Request

Every material validation SHALL begin with a Validation Request.

hecate_validation_request:
  request_id: PP-HRQ-000001
  request_version: 1.0.0

  requester:
    actor_type: component
    actor_id: component.pergamum.assertion-registry

  purpose: assertion_registry_admission

  targets:
    - object_id: PP-KA-000001
      object_version: 1.0.0
      object_digest: sha256:...

  conformance_profile:
    profile_id: PP-HCP-000001
    profile_version: 1.0.0

  context:
    tenant_scope:
      mode: none
    white_label_scope:
      mode: none
    valid_at: 2026-08-04T00:00:00Z

  provenance: {}

15.1. Required Request Fields

Every Request SHALL identify:

Request identity;
Request version;
requester;
purpose;
target objects;
target versions;
target digests;
Conformance Profile;
temporal context;
tenant context;
white-label context;
target environment;
requested receipt class;
confidentiality;
provenance.

15.2. Requester Classes

Requesters MAY include:

human reviewer;
Component;
workflow;
Agent;
CI pipeline;
Registry;
compiler;
auditor;
tenant administrator;
white-label operator;
authorised external system.

15.3. Purpose Binding

The Request SHALL be evaluated only for its declared purpose.

15.4. Target Mutation

If a target changes after Request creation, the Request SHALL:

fail;
refresh to a new version;
or resolve to a new Evidence Snapshot.

15.5. Unbounded Validation

Unbounded validation over unspecified tenant, graph or Registry scope SHALL be prohibited.

16. Target Resolution

HECATE SHALL resolve every target to:

stable object identifier;
object type;
version;
digest;
canonical location;
lifecycle;
scope;
rights;
owner;
Module;
Component.

16.1. Missing Target

A missing required target SHALL produce a blocking Finding.

16.2. Ambiguous Target

An ambiguous target SHALL produce unable_to_determine or a blocking Finding.

16.3. Derived Copy

A derived copy SHALL not be validated as canonical source unless the Profile explicitly targets the projection.

16.4. Target Set

A multi-object validation SHALL preserve target membership and ordering where material.

16.5. Target Graph Closure

A Profile MAY require dependent objects to be included in the Evidence Snapshot.

17. HECATE Evidence Snapshot

An Evidence Snapshot freezes the validation inputs and dependencies.

hecate_evidence_snapshot:
  snapshot_id: PP-HES-000001
  snapshot_version: 1.0.0

  targets:
    - object_id: PP-KA-000001
      object_version: 1.0.0
      object_digest: sha256:...

  dependencies:
    schemas:
      - schema_id: pp.schema.knowledge-assertion
        version: 1.0.0
        digest: sha256:...
    registries:
      - registry_id: pp.predicate-registry
        version: 4.0.0
        digest: sha256:...
    rights_records:
      - PP-RGT-000001@1.0.0

  temporal:
    valid_at: 2026-08-04T00:00:00Z
    transaction_at: 2026-08-04T20:00:00Z

  snapshot_digest: sha256:...
  provenance: {}

17.1. Required Snapshot Fields

Every material Snapshot SHALL identify:

Snapshot identity;
Snapshot version;
targets;
target versions and digests;
schemas;
Registries;
Rights Records;
policies;
graph version;
tenant policy;
white-label policy;
temporal context;
external evidence;
snapshot digest;
provenance.

17.2. Snapshot Immutability

A used Evidence Snapshot SHALL be immutable.

17.3. Snapshot Completeness

Completeness states MAY include:

complete;
complete with controlled redaction;
materially complete;
partial;
blocked;
unable to determine.

17.4. Incomplete Snapshot

A materially incomplete Snapshot SHALL not support a definitive pass.

17.5. Restricted Evidence

Restricted evidence SHALL remain protected throughout execution and receipt generation.

18. HECATE Execution Plan

The Execution Plan resolves the Profile and Rule dependencies into an executable graph.

hecate_execution_plan:
  plan_id: PP-HEP-000001
  plan_version: 1.0.0

  request_id: PP-HRQ-000001
  snapshot_id: PP-HES-000001

  profile:
    profile_id: PP-HCP-000001
    profile_version: 1.0.0

  resolved_rules:
    - PP-HRL-000001@1.0.0
    - PP-HRL-000002@1.0.0

  execution_policy:
    fail_fast: false
    maximum_parallelism: 8
    timeout: PT5M

  plan_digest: sha256:...
  provenance: {}

18.1. Required Plan Fields

Every Plan SHALL identify:

Plan identity;
version;
Request;
Snapshot;
Profile;
Rule Sets;
resolved Rules;
dependency order;
parallelisation;
timeout;
retry;
fail-fast policy;
resource limits;
execution environment;
output policy;
digest;
provenance.

18.2. Plan Determinism

Identical Request, Snapshot, Profile and Rule versions SHOULD produce the same Plan digest.

18.3. Plan Review

High-impact Profiles MAY require Plan approval before execution.

18.4. Plan Immutability

An executed Plan version SHALL remain immutable.

19. HECATE Validation Execution

Every execution SHALL create a Validation Execution record.

hecate_validation_execution:
  execution_id: PP-HEX-000001
  execution_version: 1.0.0

  request_id: PP-HRQ-000001
  snapshot_id: PP-HES-000001
  plan_id: PP-HEP-000001

  hecate_component:
    component_id: component.hecate.knowledge-validator
    version: 5.0.0
    build_digest: sha256:...

  environment:
    environment_id: validation.production.eu
    container_digest: sha256:...
    dependency_lock_digest: sha256:...

  started_at: 2026-08-04T20:10:00Z
  completed_at: 2026-08-04T20:10:02Z

  status: completed
  execution_digest: sha256:...
  provenance: {}

19.1. Execution Status

States MAY include:

queued;
running;
completed;
completed with warnings;
failed;
blocked;
cancelled;
timed out;
quarantined;
non-reproducible.

19.2. Execution Identity

A retry SHALL create a new Execution record.

19.3. Environment Pinning

The execution environment SHOULD preserve:

HECATE Component version;
build digest;
container or runtime digest;
dependency lock;
operating configuration;
locale;
timezone;
clock source;
network policy;
provenance.

19.4. Execution Isolation

Execution SHOULD be isolated and least-privileged.

19.5. Execution Logs

Logs SHALL be sufficient for audit without exposing prohibited source content, secrets or cross-tenant data.

19.6. Resource Exhaustion

Resource exhaustion SHALL produce a blocked or failed state, not a pass.

20. Rule Execution Result

Every executed Rule SHALL produce an explicit result.

Result states are:

passed;
failed;
warning;
informational;
not applicable;
not executed;
blocked;
unable to determine;
error.

20.1. Passed

passed means the target satisfied the exact criterion.

20.2. Failed

failed means the target did not satisfy the criterion.

20.3. Warning

warning means a non-blocking criterion or threshold was triggered.

20.4. Not Applicable

not_applicable means the Rule was evaluated for applicability and excluded.

20.5. Not Executed

not_executed means the Rule was in scope but execution did not occur.

20.6. Blocked

blocked means execution could not proceed because a dependency or policy prevented it.

20.7. Unable to Determine

unable_to_determine means available evidence was insufficient to determine conformance.

20.8. Error

error means validator or Rule execution failure.

20.9. No Silent Pass

No non-passed state SHALL be silently converted to passed.

21. Finding Object

Every failed, warning, informational, blocked, unable-to-determine or error result SHALL produce a Finding where policy requires.

finding:
  finding_id: PP-FND-000001
  finding_version: 1.0.0

  execution_id: PP-HEX-000001
  rule_id: PP-HRL-000001
  rule_version: 1.0.0

  finding_code: PP.HKCP.ASSERTION.INVALID_PREFIX
  result: failed
  severity: high

  target:
    object_id: PP-KA-000001
    object_version: 1.0.0
    path: assertion_id

  observed_value: "KA-001"
  expected_condition: "Identifier starts with PP-KA-"

  evidence:
    snapshot_id: PP-HES-000001
    evidence_path: targets[0].assertion_id

  remediation_guidance:
    action: assign_valid_identifier

  provenance: {}

21.1. Required Finding Fields

Every Finding SHALL identify:

Finding identity;
version;
Execution;
Rule;
Rule version;
Finding code;
result;
severity;
target;
target version;
object path;
observed state;
expected state;
evidence;
message;
remediation guidance where available;
lifecycle;
provenance.

21.2. Finding Identity

A Finding SHALL not be identified solely by message text.

21.3. Finding Deduplication

Duplicate Findings MAY be grouped but SHALL preserve individual target and execution lineage.

21.4. Finding Immutability

A completed Finding version SHALL be immutable.

21.5. Finding Lifecycle

States MAY include:

open;
acknowledged;
under remediation;
resolved;
accepted exception;
waived;
false positive;
superseded;
historical.

21.6. False Positive

A false-positive determination SHALL identify:

Finding;
Rule;
evidence;
reviewer;
authority;
effect on Rule or Profile;
provenance.

A false-positive determination SHALL not rewrite the original execution.

22. Finding Evidence

Finding evidence SHALL be reproducible and minimised.

Evidence MAY include:

object path;
source fragment;
schema error;
graph path;
Registry lookup;
Rights Record;
temporal interval;
digest mismatch;
signature validation;
test output;
model-assisted classification result;
human attestation.

22.1. Evidence Redaction

Sensitive evidence MAY be redacted in a receipt while remaining available to authorised reviewers.

22.2. Evidence Sufficiency

A Finding SHALL contain enough evidence to reproduce or independently review the result.

22.3. Evidence Chain

Where evidence depends on several objects, the chain SHALL be preserved.

22.4. Evidence Rights

Evidence handling SHALL respect source rights, tenant scope and confidentiality.

23. Finding Aggregation

Findings MAY be aggregated by:

target;
Rule;
Finding code;
severity;
Module;
Component;
tenant;
white-label operator;
source;
lifecycle;
remediation owner.

23.1. Aggregation Non-Erasure

Aggregation SHALL not erase individual Finding identities.

23.2. Count Semantics

Counts SHALL distinguish:

unique Findings;
affected objects;
affected tenants;
repeated executions;
accepted exceptions;
unresolved Findings.

23.3. Severity Aggregation

Overall severity SHALL not be reduced because low-severity Findings are numerous or high-severity Findings are few.

23.4. Trend Analysis

Trend metrics SHALL not replace object-level validation.

24. Gate Evaluation

A Gate converts Rule outcomes into a purpose-specific conformance result.

gate:
  gate_id: admission
  blocking:
    severities:
      - critical
      - high
    results:
      - blocked
      - error
  warning_policy:
    maximum_moderate_findings: 5
  unable_to_determine_policy: block

24.1. Gate Types

Gates MAY include:

source admission;
document admission;
assertion admission;
mapping admission;
graph admission;
retrieval eligibility;
Candidate eligibility;
projection eligibility;
release readiness;
activation admission;
Publication readiness;
assurance;
certification support.

24.2. Gate Inputs

Gate evaluation SHALL use:

Rule results;
severities;
Findings;
exceptions;
required attestations;
required evidence;
Profile policy;
target scope.

24.3. Gate Outcomes

Outcomes MAY include:

pass;
pass with warnings;
conditional pass;
fail;
blocked;
unable to determine;
expired;
revoked.

24.4. Gate Non-Authority

A Gate pass SHALL not itself issue the authoritative Decision governed by the target domain.

24.5. Gate Transparency

The receipt SHALL disclose which Rules and Findings determined the outcome.

25. Conformance Receipt

A Conformance Receipt records the validation outcome.

conformance_receipt:
  receipt_id: PP-RCPT-000001
  receipt_version: 1.0.0

  request_id: PP-HRQ-000001
  snapshot_id: PP-HES-000001
  execution_id: PP-HEX-000001

  conformance_profile:
    profile_id: PP-HCP-000001
    profile_version: 1.0.0

  targets:
    - object_id: PP-KA-000001
      object_version: 1.0.0
      object_digest: sha256:...

  outcome: failed

  summary:
    passed: 120
    failed: 1
    warnings: 2
    not_applicable: 15
    blocked: 0
    unable_to_determine: 0

  findings:
    - PP-FND-000001

  receipt_digest: sha256:...
  signature: {}
  issued_at: 2026-08-04T20:10:03Z
  expires_at: 2026-11-02T20:10:03Z
  provenance: {}

25.1. Required Receipt Fields

Every material Receipt SHALL identify:

Receipt identity;
version;
Request;
Snapshot;
Execution;
Profile and version;
target objects, versions and digests;
Rule Sets and versions;
Rules executed;
outcome;
result counts;
Findings;
exceptions;
attestations;
issued time;
expiry;
receipt digest;
signature where required;
scope;
limitations;
provenance.

25.2. Receipt Immutability

An issued Receipt SHALL be immutable.

25.3. Receipt Scope

The Receipt SHALL identify the exact:

purpose;
target;
environment;
tenant;
white-label operator;
valid time;
transaction time;
evidence scope.

25.4. Receipt Limitations

The Receipt SHALL state what it does not prove.

25.5. Receipt Expiry

A Receipt MAY expire because of:

target change;
dependency change;
Rule change;
Profile change;
rights change;
tenant policy change;
environment change;
time-based expiry;
new critical Finding;
incident.

25.6. Receipt Revocation

Revocation SHALL identify:

Receipt;
authority;
reason;
effective time;
affected downstream objects;
provenance.

25.7. Receipt Verification

A verifier SHOULD be able to validate:

digest;
signature;
issuer;
target digests;
Profile;
Rule versions;
current status;
expiry;
revocation.

26. Receipt Signing and Verification

High-impact Receipts SHOULD be signed or accompanied by a verifiable issuer attestation.

26.1. Signature Metadata

Signature metadata SHALL identify:

signature algorithm;
key identifier;
issuer;
signing time;
signed payload digest;
certificate chain where applicable;
verification status;
revocation status;
provenance.

26.2. Key Governance

Signing keys SHALL be:

access-controlled;
rotated;
revocable;
auditable;
environment-specific where required;
protected by appropriate key-management controls.

26.3. Detached Signature

A detached signature MAY be used where the Receipt payload remains independently addressable.

26.4. Verification Failure

A signature or digest verification failure SHALL invalidate trust in the Receipt and create a critical Finding or Incident.

26.5. Public Verification

A public verification endpoint MAY expose:

Receipt identity;
issuer;
target identity;
outcome;
issue time;
expiry;
revocation;
digest verification.

It SHALL not expose restricted Findings or evidence without permission.

27. Exception and Waiver Governance

An exception permits a governed deviation from a Rule or Gate for a defined scope and time.

A waiver records authorised acceptance of a known Finding or unmet criterion.

Neither SHALL be created by HECATE autonomously.

hecate_exception_decision:
  exception_id: PP-HED-000001
  exception_version: 1.0.0

  target:
    finding_id: PP-FND-000001
    rule_id: PP-HRL-000001

  treatment: temporary_exception

  scope:
    object_id: PP-KA-000001
    tenant_scope:
      mode: none

  authority:
    decision_roles:
      - knowledge-governance-owner

  conditions:
    - remediation_due_before_expiry

  effective_from: 2026-08-04T00:00:00Z
  expires_at: 2026-08-18T00:00:00Z
  provenance: {}

27.1. Required Exception Fields

Every Exception Decision SHALL identify:

Exception identity;
version;
Finding or Rule;
target;
scope;
reason;
authority;
risk;
conditions;
effective time;
expiry;
review date;
remediation;
prohibited uses;
provenance.

27.2. Exception Classes

Classes MAY include:

temporary exception;
permanent accepted deviation;
compensating control;
false-positive treatment;
transitional waiver;
historical-only waiver;
emergency waiver;
tenant-specific exception.

27.3. Exception Scope

An exception SHALL be no broader than necessary.

27.4. Exception Non-Transitivity

An exception for one object, tenant, version, Rule or purpose SHALL not transfer automatically to another.

27.5. Exception Expiry

Expired exceptions SHALL cease to affect new Gate evaluations.

27.6. Critical and Constitutional Rules

Critical or constitutional Rules MAY prohibit waiver.

27.7. Emergency Waiver

Emergency waiver SHALL require:

emergency basis;
temporary authority;
compensating controls;
short expiry;
monitoring;
mandatory retrospective review;
rollback or containment;
provenance.

27.8. Waiver Visibility

Receipts SHALL disclose applicable exceptions and waivers.

28. Compensating Controls

A compensating control SHALL identify:

original Rule;
unmet criterion;
alternative control;
control owner;
evidence;
effectiveness test;
monitoring;
scope;
expiry;
Decision authority;
provenance.

A compensating control SHALL not be treated as equivalent to the original criterion unless an approved governing framework states equivalence.

28.1. Effectiveness Validation

HECATE MAY validate objective evidence of compensating-control operation.

28.2. Effectiveness Decision

HECATE SHALL not decide whether a disputed compensating control is legally or semantically sufficient.

28.3. Control Failure

Failure of a compensating control SHALL revoke or block the associated exception according to policy.

29. Remediation Plan

A Remediation Plan governs correction of Findings.

hecate_remediation_plan:
  remediation_id: PP-HRP-000001
  remediation_version: 1.0.0

  findings:
    - PP-FND-000001

  actions:
    - action_id: remediation-action-001
      action_type: correct_identifier
      owner: component.pergamum.assertion-registry
      due_at: 2026-08-06T00:00:00Z
      validation_profile: PP-HCP-000001@1.0.0

  status: active
  provenance: {}

29.1. Required Remediation Fields

Every material Plan SHALL identify:

Plan identity;
version;
Findings;
root cause;
actions;
owners;
priority;
due dates;
dependencies;
expected evidence;
revalidation Profile;
rollback or containment;
status;
provenance.

29.2. Remediation States

States MAY include:

proposed;
approved;
active;
blocked;
completed;
validated;
ineffective;
superseded;
cancelled.

29.3. Remediation Non-Mutation

HECATE SHALL not silently remediate the evaluated object during validation.

29.4. Auto-Fix Candidate

HECATE MAY generate a correction candidate where:

the repair is deterministic;
policy permits it;
the original object remains preserved;
the proposed diff is explicit;
no authority is created;
separate review and Change Candidate governance apply.

29.5. Revalidation

Remediation SHALL be confirmed through a new Validation Request and Receipt.

30. Revalidation

Revalidation SHALL create new:

Request;
Evidence Snapshot;
Execution Plan;
Execution;
Findings;
Receipt.

30.1. Prior Receipt Linkage

The new Receipt SHOULD link to:

prior Receipt;
remediated Findings;
Exception Decisions;
changed object versions;
changed Rule or Profile versions;
remediation evidence.

30.2. Partial Revalidation

Partial revalidation MAY occur only where:

affected Rules are deterministically identified;
dependencies are unchanged;
Profile policy permits it;
the Receipt clearly limits scope.

30.3. Full Revalidation Triggers

Full revalidation SHOULD occur after:

material object change;
schema migration;
Rule Set change;
rights change;
tenant-scope change;
security incident;
compiler change;
projection regeneration;
activation rollback;
historical-replay dispute.

30.4. Pass After Remediation

A new pass SHALL not erase prior failure history.

31. HECATE Baseline

A Baseline defines an approved conformance state for comparison.

hecate_baseline:
  baseline_id: PP-HBL-000001
  baseline_version: 1.0.0
  purpose: knowledge-registry-production

  profile:
    profile_id: PP-HCP-000001
    profile_version: 1.0.0

  accepted_receipts:
    - PP-RCPT-000001

  object_snapshot_digest: sha256:...
  effective_from: 2026-08-04T00:00:00Z
  provenance: {}

31.1. Baseline Uses

Baselines MAY support:

drift detection;
release comparison;
tenant comparison;
white-label comparison;
audit;
historical reconstruction;
incident analysis.

31.2. Baseline Immutability

A Baseline version SHALL be immutable.

31.3. Baseline Non-Authority

A Baseline records an approved comparison state; it does not independently create authority.

31.4. Baseline Drift

Drift SHALL identify:

added objects;
removed objects;
changed objects;
changed Findings;
changed exceptions;
changed receipts;
severity changes;
provenance.

32. Structural and Schema Conformance

HECATE SHALL support validation of:

syntax;
media type;
schema identity;
schema version;
required fields;
datatype;
enum;
pattern;
numeric constraints;
array cardinality;
object shape;
conditional fields;
references;
extension fields;
unknown-field policy.

32.1. Schema Pinning

The evaluated schema version SHALL be pinned.

32.2. Unknown Fields

Unknown fields SHALL be treated according to Profile policy:

prohibited;
warning;
permitted in extension namespace;
ignored with explicit disclosure.

32.3. Default Values

HECATE SHALL not silently apply defaults unless the governing schema explicitly defines and authorises them.

32.4. Schema Repair

Schema repair MAY be proposed but SHALL not modify the target during validation.

32.5. Multiple Schemas

Where several schemas apply, precedence and composition SHALL be explicit.

33. Identity Conformance

HECATE SHALL validate, where applicable:

prefix;
uniqueness;
immutability;
non-reuse;
semantic identifier structure;
external identifier separation;
version identity;
alias structure;
canonical name;
tombstone preservation.

33.1. Collision

Identifier collision SHALL be high or critical according to scope.

33.2. Retired Identifier

Reuse of a retired identifier SHALL fail.

33.3. Storage-Path Independence

HECATE MAY validate that identity does not depend on mutable storage path.

33.4. Semantic Identifier

A semantic identifier collision SHALL be reviewed according to object class.

33.5. Alias Non-Identity

An alias SHALL not satisfy a Rule requiring stable identity.

34. Lifecycle Conformance

HECATE SHALL validate:

permitted states;
permitted transitions;
transition authority;
transition time;
conditions;
predecessor and successor;
supersession;
withdrawal;
retirement;
deletion tombstone;
historical preservation.

34.1. Invalid Transition

An invalid lifecycle transition SHALL fail.

34.2. Missing Transition Receipt

A high-impact transition without its required Decision or receipt SHALL fail.

34.3. Superseded Active Object

An object marked both superseded and current-active without a permitted overlap SHALL fail.

34.4. Withdrawal Propagation

HECATE MAY validate that required dependent objects have entered review, restricted or historical states.

35. Bitemporal Conformance

HECATE SHALL validate:

valid_from;
valid_to;
transaction time;
recording time;
supersession time;
interval ordering;
timezone;
temporal precision;
open intervals;
unknown-time representation;
overlapping incompatible validity.

35.1. Valid-Time Logic

valid_to SHALL not precede valid_from.

35.2. Transaction-Time Logic

Historical transaction records SHALL be append-only where required.

35.3. Retroactive Recording

Retroactive records SHALL preserve later transaction time.

35.4. Temporal Conflict

Overlapping incompatible states SHALL create Findings or conflict objects.

35.5. Current-State Query

A current-state validation SHALL use an explicit current-time basis.

36. Provenance Conformance

HECATE SHALL validate provenance completeness appropriate to object class and conformance level.

Validation MAY include:

creator;
creation time;
source lineage;
transformation lineage;
reviewer;
Decision;
compiler;
model;
prompt;
tool;
tenant;
white-label operator;
Module;
Component;
valid time;
transaction time.

36.1. Provenance Graph Integrity

Referenced provenance nodes and edges SHALL exist and be type-valid.

36.2. Provenance Completeness State

The object's declared completeness state SHALL be supported by available lineage.

36.3. Materially Incomplete Provenance

Materially incomplete provenance SHALL block high-impact admission, projection, Publication or activation.

36.4. Controlled Redaction

Controlled redaction SHALL preserve a verifiable placeholder and authorisation.

36.5. Circular Provenance

Invalid circular derivation SHALL fail.

37. Rights Conformance

HECATE SHALL validate objective rights metadata including:

Rights Record identity;
target relationship;
holder or explicit unresolved state;
permission basis;
licence or agreement;
validity;
territory;
audience;
purpose;
channel;
processing rights;
Publication rights;
attribution;
expiration;
revocation;
rights evidence;
rights Decision.

37.1. Unknown Permission

Unknown or omitted permission SHALL not pass a Rule requiring permission.

37.2. Most-Restrictive Rule

HECATE MAY deterministically apply the most-restrictive applicable Rights Record.

37.3. Rights Legal Judgement

HECATE SHALL not decide disputed ownership, fair use, fair dealing or legal interpretation.

37.4. Rights Gate

A Rights Gate result SHALL be validated for identity, scope, time and intended use.

37.5. Revocation Propagation

HECATE MAY validate propagation to chunks, embeddings, indexes, projections and Publications.

38. Authority Conformance

HECATE SHALL validate that authority dimensions are:

present where required;
structurally separate;
scope-bound;
versioned;
non-transitive;
consistent with approved Decisions;
not escalated by derivation.

38.1. Authority Dimensions

Validation MAY cover:

source authority;
legal authority;
evidentiary authority;
ZAYAZ governance authority;
Runtime authority.

38.2. Authority Escalation

An object claiming greater authority than its approved Decision permits SHALL fail.

38.3. Runtime Authority

Runtime authority without Activation Record SHALL fail.

38.4. HECATE Authority

A target SHALL not cite a HECATE pass as the sole source of semantic or legal authority.

39. Tenant and White-Label Conformance

HECATE SHALL validate:

tenant identity;
white-label operator identity;
object scope;
relationship scope;
index scope;
cache scope;
Context Package scope;
projection scope;
Publication scope;
cross-scope references;
promotion Decisions;
deletion;
retention.

39.1. Cross-Tenant Reference

An unauthorised cross-tenant reference SHALL be critical.

39.2. White-Label Leakage

An unauthorised white-label cross-reference SHALL be critical.

39.3. Global Promotion

Promotion to global canonical scope SHALL require the identified rights, confidentiality, semantic and governance Decisions.

39.4. Scope Narrowing

Scope narrowing SHALL not invalidate historical lineage.

39.5. Shared Infrastructure

Shared infrastructure SHALL demonstrate enforceable logical, cryptographic or physical isolation appropriate to risk.

40. Module and Component Lineage Conformance

HECATE SHALL validate both Module and Component lineage.

Validation MAY include:

accountable Module;
owning Component;
source Component;
transformation Component;
validation Component;
target Component;
Runtime-consuming Component;
Publication-consuming Component;
archive Component.

40.1. Orphan Component

A material object affecting execution without Component lineage SHALL fail the applicable governance Rule.

40.2. Invalid Module Membership

A Component referencing an invalid or incompatible Module SHALL fail.

40.3. Lineage Preservation

Projection and Publication objects SHALL preserve source Module and Component lineage.

40.4. Pergamum Pulse Requirement

Pergamum Pulse lineage SHALL preserve both the originating Module and the specific Component responsible for each transformation.

41. Knowledge Object Conformance

HECATE SHALL validate the universal object contract defined by PP-KORS.

Validation MAY include:

stable object identifier;
object type;
semantic identifier;
canonical name;
aliases;
version;
lifecycle;
temporal validity;
scope;
authority;
relationships;
owner;
classification;
provenance.

41.1. Object-Class Contract

Each object class SHALL be validated against its specific contract.

41.2. Object Version

A material object version SHALL be resolvable and immutable after publication or approval.

41.3. Bundle Non-Aggregation

A Knowledge Bundle SHALL not merge member authority, rights or lifecycle.

41.4. Source Separation

HECATE SHALL validate separation among:

Source Series;
Source Object;
Source Capture;
Knowledge Document;
Knowledge Entity.

41.5. Fragment Separation

HECATE SHALL validate separation between Source Fragment and Knowledge Assertion.

42. Relationship and Graph Conformance

HECATE SHALL validate:

relationship identity where required;
relationship type;
source object;
target object;
direction;
inverse;
symmetry;
transitivity;
cardinality;
source and target class constraints;
scope;
authority;
temporal validity;
provenance.

42.1. Relationship Type Registry

Every relationship type SHALL resolve to an approved Registry version.

42.2. Dangling Relationship

A relationship referencing a missing object SHALL fail.

42.3. Cardinality Violation

A cardinality violation SHALL produce a Finding appropriate to impact.

42.4. Invalid Transitivity

A composed relationship using a non-transitive type SHALL fail.

42.5. Invalid Cycle

A cycle SHALL fail where the relationship type prohibits cycles.

42.6. Rights-Aware Graph

HECATE MAY validate that graph projections exclude or protect restricted nodes and edges.

42.7. Historical Graph

Historical validation SHALL use the graph version applicable at the target time.

43. Knowledge Assertion Conformance

HECATE SHALL validate objective assertion structure defined by PP-KAS.

Validation SHALL include, where applicable:

PP-KA- identity;
assertion version;
assertion type;
canonical statement;
subject kind;
predicate registration;
object kind;
subject-class constraints;
object-class constraints;
Source Fragment linkage;
normative force;
authority;
rights;
applicability;
confidence structure;
temporal validity;
review state;
conflict state;
provenance.

43.1. Source Evidence

A material source-supported assertion without exact Source Fragment evidence SHALL fail.

43.2. Unsupported AI Assertion

An AI-generated assertion without exact support SHALL not pass source-supported admission.

43.3. Predicate Validity

The predicate and version SHALL resolve to the approved Predicate Registry.

43.4. Null Semantics

Unknown, not stated, not applicable, prohibited, unavailable and redacted SHALL remain distinguishable.

43.5. Quantitative Assertion

HECATE MAY validate:

datatype;
unit;
precision;
range;
threshold operator;
unit dimension;
conversion lineage;
significant figures.

43.6. Formula Assertion

HECATE MAY validate formula syntax, variable completeness and dimensional consistency.

HECATE SHALL not decide disputed methodology validity.

43.7. Certification Assertion

HECATE SHALL validate certificate identity, scope, validity and authority metadata without creating certification status.

44. Mapping and Crosswalk Conformance

HECATE SHALL validate objective requirements defined by PP-SMCS.

Validation SHALL include:

PP-MAP- identity;
Mapping Object version;
Mapping Type;
source and target;
pinned versions;
direction;
cardinality;
rationale;
Mapping Evidence;
authority;
rights;
applicability;
confidence;
coverage;
lossiness;
temporal validity;
review;
conflict state;
Crosswalk membership;
provenance.

44.1. Equivalence Structure

HECATE MAY validate whether required equivalence-analysis fields are present.

HECATE SHALL not independently decide semantic, legal or certification equivalence.

44.2. Exact Equivalence Claim

An exact-equivalence mapping lacking required scope, authority, condition or evidence analysis SHALL fail.

44.3. No-Mapping and Gaps

A Crosswalk claiming completeness SHALL account for reviewed no-map and gap objects.

44.4. Mapping Composition

HECATE MAY validate composition Rules, path completeness, rights and non-transitivity.

44.5. Coverage

Coverage percentages SHALL be structurally valid and SHALL not exceed permitted bounds.

44.6. Mapping Conflict

A blocking Mapping Conflict SHALL prevent applicable admission or projection Gate passage.

45. Citation and Publication-Rights Conformance

HECATE SHALL validate objective citation and Publication-rights requirements defined by PP-RLCPS.

Validation MAY include:

Citation Object identity;
source identity;
source version;
exact locator;
source link or controlled reference;
quotation versus paraphrase;
attribution;
Rights Record;
publication permission;
quotation limits;
access date;
Modification notice;
Publication Package completeness.

45.1. Fabricated Citation

A citation target that cannot be resolved SHALL fail.

45.2. Quotation Rights

A quotation exceeding an objective recorded limit SHALL fail.

45.3. Attribution

Missing required attribution SHALL fail the applicable Publication Gate.

45.4. Publication Non-Authority

HECATE validation of a Publication Package SHALL not approve Publication.

45.5. Withdrawal Status

A Publication relying on a withdrawn source or revoked right SHALL trigger review or fail according to Profile policy.

46. Retrieval Eligibility Conformance

HECATE SHALL validate objective requirements defined by PP-REAPP.

Validation MAY include:

Retrieval Eligibility Record;
object identity and version;
Rights Records;
security classification;
tenant scope;
white-label scope;
permitted operations;
conditions;
expiry;
provenance.

46.1. No Eligibility Record

An object requiring eligibility evaluation SHALL not be chunked, indexed, embedded or processed without the Record.

46.2. Prohibited Operation

An embedding or RAG operation marked prohibited SHALL fail admission.

46.3. Expired Eligibility

Expired eligibility SHALL not pass current processing admission.

46.4. Purpose Mismatch

Use outside the approved purpose SHALL fail or require renewed eligibility.

47. Chunk and Embedding Conformance

HECATE SHALL validate:

PP-CHK- identity;
source object and version;
Source Fragment or structural locator;
chunking Profile;
offsets;
content digest;
language;
token count;
rights;
scope;
provenance;
PP-EMB- identity;
source chunk;
Embedding Profile;
model version;
dimensions;
vector-store reference;
lifecycle;
deletion state.

47.1. Chunk Lineage

A chunk without exact source lineage SHALL fail.

47.2. Formula or Table Split

HECATE MAY validate prohibited structural splits where the Chunking Profile defines them.

47.3. Embedding Dimension

Embedding dimensions SHALL match the approved Embedding Profile and index.

47.4. Mixed Embedding Space

Incompatible embeddings in one index SHALL fail unless an approved compatibility Profile exists.

47.5. Deleted Embedding

A deleted or deletion-pending embedding SHALL not remain active in a current index.

47.6. Rights Propagation

Chunk and embedding rights SHALL be consistent with source and fragment Rights Records.

48. Retrieval Session and Context Conformance

HECATE SHALL validate:

Retrieval Request;
purpose;
requester;
scope;
temporal context;
Retrieval Plan;
index versions;
filters;
ranking configuration;
result limits;
Retrieval Session;
Retrieval Results;
Context Package;
token budget;
Prompt Profiles;
rights;
tenant scope;
digest;
provenance.

48.1. Pre-Exposure Filtering

A Plan using post-exposure filtering where pre-exposure filtering is required SHALL fail.

48.2. Cross-Tenant Result

A Retrieval Result outside authorised tenant scope SHALL be critical.

48.3. Context Digest

The Context Package digest SHALL match the included ordered content.

48.4. Omitted Conflict

Where a Profile requires conflict visibility, omission of a material known conflict SHALL produce a Finding.

48.5. Token Overflow

Context exceeding the declared model or Profile limit SHALL fail.

48.6. Prompt Profile Resolution

All Prompt Profiles SHALL resolve to approved versions.

49. AI Processing Conformance

HECATE SHALL validate objective AI-processing requirements including:

AI Processing Task;
purpose;
requester;
Context Package;
Model Profile;
Prompt Profiles;
permitted tools;
output schema;
review requirement;
AI Inference Record;
model version;
parameters;
Tool Invocation Records;
output digest;
Grounding Records;
Citation Objects;
evaluation;
provenance.

49.1. Model Eligibility

The model SHALL be approved for the Task and data classification.

49.2. Provider Policy

External provider region, retention and provider-training use SHALL satisfy policy.

49.3. Tool Permission

A Tool Invocation outside the Agent, Task or user permission SHALL fail.

49.4. Structured Output

Machine-actionable output SHALL pass the approved output schema.

49.5. Grounding Completeness

High-impact source-derived claims without required Grounding Records SHALL fail or be blocked.

49.6. Citation Resolution

Citations SHALL resolve to eligible retrieved objects.

49.7. Prompt Injection

HECATE MAY validate that detected prompt-injection content was labelled, isolated or blocked according to policy.

49.8. Review Requirement

A high-impact Task without required competent review SHALL fail downstream admission.

49.9. AI Non-Authority

A model output SHALL not pass a Rule requiring human or organisational authority.

50. Change Candidate Conformance

HECATE SHALL validate objective Candidate requirements defined by PP-CCPS.

Validation SHALL include, where applicable:

PP-CC- identity;
Candidate version;
source basis;
target identity;
target version;
target digest;
proposed operation;
expected current state;
proposed state;
rationale;
Impact Assessment;
Dependency Assessment;
risk;
authority;
rights;
applicability;
review;
conflict;
temporal validity;
provenance.

50.1. Unsupported Candidate

A Candidate claiming source mandate without sufficient source basis SHALL fail.

50.2. Target Drift

A target whose current digest differs from the expected digest SHALL fail projection eligibility.

50.3. Hidden Change

A Candidate payload containing undisclosed unrelated changes SHALL fail.

50.4. Secret Detection

Secrets in Candidate payloads SHALL produce critical Findings.

50.5. Destructive Change

A destructive Candidate lacking required rollback or compensating treatment SHALL fail.

50.6. Dependency Cycle

A blocking dependency cycle SHALL fail.

50.7. Candidate Conflict

Unresolved blocking Candidate Conflict SHALL prevent projection eligibility.

51. Change Decision Conformance

HECATE SHALL validate:

PP-CD- identity;
Candidate and version;
approved operation;
approved payload digest;
authority;
conditions;
scope;
effective time;
expiry;
signatures where required;
provenance.

51.1. Decision Mismatch

A Decision referring to a different Candidate version or payload digest SHALL fail.

51.2. Expired Decision

An expired Decision SHALL not authorise new projection.

51.3. Unsatisfied Condition

A blocking unsatisfied Decision Condition SHALL prevent the declared Gate from passing.

51.4. Decision Authority

HECATE SHALL validate the presence and identity of authority evidence, not decide whether disputed authority is substantively sufficient.

51.5. Decision Immutability

Mutation of an issued Decision SHALL invalidate trust and create an Incident.

52. Projection Conformance

HECATE SHALL validate:

PP-PRJ- identity;
Projection Manifest version;
Candidates or Candidate Package;
Change Decisions;
Decision Conditions;
pinned inputs;
input digests;
compiler identity;
compiler version;
configuration digest;
build environment;
Generated Artefacts;
artefact digests;
validation receipts;
rights;
scope;
release state;
activation state;
provenance.

52.1. Missing Decision

A projection without an applicable approved Change Decision SHALL fail.

52.2. Unpinned Input

A production projection depending on unpinned mutable input SHALL fail.

52.3. Artefact Digest

Generated Artefact digests SHALL match the Manifest.

52.4. Deterministic Build

Where deterministic generation is required, reproducibility mismatch SHALL produce a high or critical Finding.

52.5. Cross-Artefact Consistency

HECATE MAY validate consistency among schemas, Registries, validators, tests, workflows and documentation.

52.6. Release Versus Activation

A released artefact without Activation Record SHALL not be reported as active.

52.7. Activation Digest

Activated artefact digests SHALL match released and approved digests.

53. Runtime Admission Boundary

HECATE MAY support Runtime admission validation.

It SHALL validate objective preconditions such as:

active Release;
valid Activation Request;
Activation authority evidence;
target environment;
target current state;
artefact digests;
migration readiness;
rollback readiness;
monitoring readiness;
tenant scope;
security;
provenance.

53.1. Activation Non-Execution

HECATE SHALL not perform activation solely because admission passes.

53.2. Partial Activation

A partial activation SHALL identify exact successful and failed scope.

53.3. Activation Drift

Any difference between approved, released and active artefacts SHALL fail trust validation.

53.4. Rollback State

A rolled-back artefact SHALL not remain reported as current-active.

54. Publication Readiness Boundary

HECATE MAY validate objective Publication readiness.

Validation MAY include:

Publication Package;
source objects;
citations;
Rights Records;
Rights Decisions;
attribution;
quotation limits;
redactions;
reviewer records;
release version;
public claim boundaries;
correction and withdrawal path.

54.1. Publication Approval

A pass SHALL not approve Publication.

54.2. Claim Support

HECATE MAY validate that material claims have required Grounding Records or approved evidence relationships.

54.3. Current Source Status

A Publication relying on stale, withdrawn or superseded sources SHALL be treated according to the approved Profile.

54.4. Public Verification

HECATE MAY validate the integrity of a public verification record.

55. Certification and Assurance Boundary

HECATE MAY validate objective completeness of:

certification scheme identity;
criterion identity;
Evidence Requirements;
test results;
Certification Body identity;
Accreditation Body identity;
certificate scope;
validity;
signature;
Findings;
remediation;
audit trail.

HECATE SHALL NOT:

issue a certificate;
decide certification;
expand certificate scope;
declare accreditation;
substitute for a Certification Body;
convert conformance evidence into certification status.

55.1. Scheme Rule Source

Certification Rules SHALL link to authorised scheme sources.

55.2. Evidence Scope

Evidence SHALL match the assessed object, period and criterion.

55.3. Certificate Validity

Expired, suspended, withdrawn or out-of-scope certificates SHALL not pass current-validity Rules.

56. Security Conformance

HECATE SHALL support validation of objective security controls including:

authentication;
authorisation;
least privilege;
separation of duties;
tenant isolation;
white-label isolation;
encryption;
key references;
signing;
digest verification;
secrets exclusion;
build isolation;
dependency pinning;
logging;
tamper evidence;
backup;
recovery;
Incident handling.

56.1. Security Rule Authority

Security Rules SHALL link to approved policy, architecture, specification or control objective.

56.2. Secret Handling

Detected secrets in knowledge, prompts, Candidates, logs or artefacts SHALL be treated according to severity and containment policy.

56.3. Supply-Chain Validation

HECATE MAY validate:

dependency lock;
build digest;
SBOM;
signature;
provenance;
vulnerability policy state.

56.4. Vulnerability Judgement

HECATE SHALL not invent vulnerability severity beyond approved sources or policy.

57. Privacy and Personal-Data Conformance

HECATE MAY validate objective metadata including:

lawful-basis reference;
purpose;
data categories;
data-subject categories;
minimisation;
retention;
region;
processor;
tenant scope;
deletion state;
access controls;
provenance.

HECATE SHALL not make disputed legal determinations regarding privacy law.

57.1. Special Categories

Missing enhanced controls for designated special-category data SHALL fail the applicable Profile.

57.2. Retention

Expired retention without lawful hold or deletion treatment SHALL produce a Finding.

57.3. Data Subject Requests

HECATE MAY validate propagation records for access, correction or deletion workflows.

58. Historical Conformance

HECATE SHALL support historical validation against:

historical target versions;
historical Rule versions;
historical Profile versions;
historical schemas;
historical Registries;
historical Rights Records;
historical tenant policy;
historical graph state;
historical compiler or model metadata.

58.1. Exact Historical Validation

Exact historical validation SHALL answer whether the object conformed under the Rules in force at the relevant time.

58.2. Current-Rule Reassessment

A current-Rule reassessment of historical objects SHALL be labelled separately.

58.3. Non-Retroactivity

Current Rules SHALL not be silently substituted into historical receipts.

58.4. Historical Exception

Historical exceptions and waivers SHALL remain visible.

58.5. Historical Receipt Status

A historical Receipt MAY be:

valid for historical purpose;
expired for current use;
revoked;
superseded;
unable to verify.

59. Model-Assisted Validation

HECATE MAY use model-assisted checks only where approved.

Examples MAY include:

likely missing attribution;
likely unsupported assertion;
semantic inconsistency candidate;
probable duplicate entity;
probable mapping conflict;
prompt-injection candidate;
sensitive-data candidate;
remediation suggestion.

59.1. Assisted Result Classification

Model-assisted results SHALL be classified as:

candidate Finding;
heuristic warning;
review recommendation;
unable to determine.

They SHALL NOT be represented as deterministic failure unless an approved deterministic Rule confirms them.

59.2. Model Profile

Every model-assisted Rule SHALL identify:

Model Profile;
model version;
Prompt Profile;
Context Package;
thresholds;
evaluation;
known limitations;
tenant scope;
rights;
provenance.

59.3. Human Review

High-impact model-assisted Findings SHALL require human review before authoritative treatment.

59.4. Provider Restrictions

Restricted validation evidence SHALL not be sent to unauthorised providers.

59.5. Drift

Model or Prompt drift SHALL trigger Rule evaluation and potential suspension.

60. Human Attestation

Some conformance criteria require human or organisational attestation.

hecate_attestation:
  attestation_id: PP-HAT-000001
  attestation_version: 1.0.0

  criterion:
    rule_id: PP-HRL-000901
    statement: "The semantic interpretation was reviewed by a competent domain expert."

  attestor:
    actor_id: actor.example
    role: domain-expert
    competence_record: competence.ai-governance

  target:
    object_id: PP-MAP-000001
    object_version: 1.0.0

  signed_at: 2026-08-04T21:00:00Z
  expires_at: 2027-08-04T21:00:00Z
  signature: {}
  provenance: {}

60.1. Required Attestation Fields

Every Attestation SHALL identify:

Attestation identity;
version;
criterion;
target;
attestor;
Role;
competence;
scope;
statement;
evidence;
signature where required;
effective time;
expiry;
conflict of interest;
provenance.

60.2. Attestation Verification

HECATE MAY validate the identity, signature, competence record and expiry of an Attestation.

60.3. Attestation Non-Substitution

A human Attestation SHALL not substitute for objective evidence where the Rule requires objective validation.

60.4. Revocation

Attestation revocation SHALL trigger affected-receipt analysis.

61. HECATE Operational Governance

HECATE SHALL operate as a governed validation service.

Operational governance SHALL define:

service owner;
Module owner;
Component owner;
Rule Registry owner;
Profile Registry owner;
security owner;
incident owner;
availability objectives;
performance objectives;
maintenance;
change management;
backup;
recovery;
audit;
retirement.

61.1. Service States

Service states MAY include:

active;
degraded;
maintenance;
suspended;
quarantined;
retired;
historical only.

61.2. Degraded Mode

Degraded mode SHALL not silently omit required Rules or weaken security, rights or tenant boundaries.

61.3. Rule Registry Availability

If a required Rule or Profile cannot be resolved, validation SHALL be blocked rather than silently using an unapproved fallback.

61.4. Time Source

Time-dependent validation SHALL use an identified trusted clock source.

61.5. Locale and Encoding

Locale, character encoding and normalisation settings SHALL be explicit where they may affect validation.

62. Availability, Resilience and Recovery

HECATE SHALL define:

recovery time objective;
recovery point objective;
Rule Registry recovery;
Profile Registry recovery;
receipt-store recovery;
Finding-store recovery;
evidence-snapshot recovery;
key recovery;
historical replay;
integrity verification.

62.1. Recovery Integrity

Recovery SHALL validate:

object identities;
Rule and Profile versions;
Evidence Snapshot digests;
Finding identities;
Receipt digests;
signatures;
exception state;
tenant scope;
provenance.

62.2. Backup Rights

Backups SHALL preserve rights, confidentiality, tenant and white-label boundaries.

62.3. Recovery Non-Reinterpretation

Recovery SHALL not apply newer Rules or Profiles to historical Receipts.

62.4. Disaster Recovery Test

Critical deployments SHOULD test disaster recovery periodically.

63. Performance and Resource Governance

Performance controls MAY include:

maximum target count;
maximum graph depth;
maximum snapshot size;
maximum Rule duration;
execution timeout;
memory limit;
concurrency limit;
external-call limit;
result-size limit.

63.1. Performance Non-Bypass

Resource limits SHALL not convert incomplete validation to pass.

63.2. Partial Execution

Partial execution SHALL disclose every Rule not executed.

63.3. Prioritisation

Critical security, rights and tenant-isolation Rules MAY receive execution priority.

63.4. Caching

Validation caches SHALL include:

target digest;
Snapshot digest;
Rule version;
Profile version;
environment;
tenant;
valid time;
rights state.

A cache SHALL not return a broader or stale result.

63.5. Cache Invalidation

Caches SHALL be invalidated after material target, Rule, Profile, rights, tenant or dependency change.

64. Rule and Profile Change Governance

Changes to Rules or Profiles SHALL follow governed change control.

A Rule or Profile Change Candidate SHALL identify:

source requirement;
current version;
proposed version;
proposed difference;
impact;
affected targets;
affected Receipts;
affected gates;
severity changes;
migration;
test fixtures;
rollout;
rollback;
provenance.

64.1. Severity Change

A severity change is material and SHALL require review.

64.2. Retrospective Effect

A Rule change SHALL state whether it affects:

future validation only;
current-object reassessment;
historical replay;
revoked prior Receipts.

64.3. Emergency Rule

An emergency Rule SHALL be time-bound and retrospectively reviewed.

64.4. Canary Rule Deployment

New Rule versions MAY run in shadow or canary mode before becoming gating.

64.5. Shadow Findings

Shadow-mode Findings SHALL be clearly marked non-gating.

65. Drift Detection

HECATE SHALL monitor for:

Rule drift;
Profile drift;
schema drift;
Registry drift;
implementation drift;
environment drift;
model-assisted Rule drift;
severity drift;
tenant-policy drift;
external-dependency drift.

65.1. Drift Record

A drift record SHALL identify:

expected state;
observed state;
affected Rules or Profiles;
impact;
detection time;
remediation;
provenance.

65.2. Undeclared Drift

Undeclared drift in a gating Rule implementation SHALL invalidate trust in affected Receipts.

65.3. Model-Assisted Drift

Material model-assisted drift SHALL suspend or downgrade the Rule until re-evaluated.

65.4. Environment Drift

A changed runtime, container, dependency or policy environment SHALL be evaluated for reproducibility impact.

66. HECATE Incident Management

Incidents MAY include:

incorrect Rule implementation;
Rule Registry compromise;
Profile Registry compromise;
signature-key compromise;
false pass;
systematic false failure;
tenant leakage;
rights leakage;
restricted evidence exposure;
receipt forgery;
digest mismatch;
execution tampering;
audit-log loss;
unavailable historical Rule;
non-reproducible validation;
model-assisted validator drift;
bypassed Gate;
unauthorised exception;
activation based on invalid Receipt.

Every HECATE Incident SHALL identify:

Incident identity;
severity;
detection;
affected Rules;
affected Profiles;
affected Executions;
affected Findings;
affected Receipts;
affected targets;
affected tenants;
affected white-label operators;
affected releases or activations;
containment;
revocation;
revalidation;
notification;
root cause;
remediation;
provenance.

66.1. False Pass

A confirmed false pass SHALL trigger:

affected-receipt identification;
receipt revocation or caution;
downstream impact analysis;
revalidation;
Incident handling;
provenance.

66.2. False Failure

A false failure SHALL not erase the original execution.

It SHALL be treated through Rule correction, false-positive Decision and revalidation.

66.3. Key Compromise

Signing-key compromise SHALL trigger verification and revocation analysis over affected Receipts.

66.4. Evidence Preservation

Incident evidence SHALL preserve chain of custody.

67. Observability and Audit Logging

HECATE observability SHALL cover:

Requests;
target resolution;
Snapshot creation;
Profile resolution;
Rule resolution;
Plan creation;
execution;
external calls;
Findings;
Gate evaluation;
Receipt issuance;
signature verification;
exceptions;
remediation;
revalidation;
revocation;
Incident handling.

67.1. Correlation

Material validation objects SHOULD share correlation identifiers.

67.2. Sensitive Logging

Logs SHALL minimise restricted content, personal data, secrets, tenant data and confidential evidence.

67.3. Tamper Evidence

High-impact validation logs SHOULD be tamper-evident.

67.4. Log Retention

Retention SHALL be purpose-, rights-, privacy-, assurance- and Legal-Hold-aware.

67.5. Log Access

Access SHALL be least-privileged and tenant-aware.

68. Assurance and Audit

HECATE itself SHALL be subject to assurance.

Assurance MAY evaluate:

Rule authority;
Rule implementation;
fixture coverage;
deterministic execution;
Profile governance;
severity governance;
Evidence Snapshot integrity;
tenant isolation;
rights protection;
Finding completeness;
Receipt integrity;
exception governance;
remediation;
historical replay;
Incident response;
operational resilience.

68.1. Audit Record

An audit SHALL identify:

audit identity;
scope;
criteria;
auditor;
independence;
sample;
evidence;
Findings;
conclusion;
remediation;
provenance.

68.2. Rule Sampling

Audit sampling SHOULD include:

passing cases;
failing cases;
boundary cases;
exceptions;
historical cases;
tenant cases;
rights-restricted cases;
model-assisted cases.

68.3. Independent Validation

Critical HECATE controls SHOULD receive independent validation appropriate to risk.

68.4. Assurance Non-Certification

Assurance of HECATE does not certify every object validated by HECATE.

69. Historical Validation Replay

Historical replay SHALL preserve:

historical Request;
historical target versions;
historical Evidence Snapshot;
historical Profile;
historical Rule Sets;
historical Rule implementations;
historical environment;
historical Findings;
historical exceptions;
historical Receipt;
later revocation or remediation.

69.1. Exact Replay

Exact Replay SHALL use the exact historical inputs and versions where available.

69.2. Receipt Verification Replay

Receipt Verification Replay SHALL verify the original receipt digest, signature and target digests without rerunning Rules.

69.3. Rule Re-Execution Replay

Rule Re-Execution Replay SHALL rerun the historical Rule implementation against the historical Snapshot.

69.4. Current-Baseline Reassessment

A current-baseline reassessment SHALL be labelled as a new validation, not a reconstruction of the old result.

69.5. Reproducibility Limitation

Unavailable external evidence, model versions or environments SHALL be disclosed.

69.6. Digest Mismatch

Unexpected digest mismatch SHALL create a Finding or Incident.

70. Conformance Levels

70.1. Level 1 — Structurally Validated

The implementation has:

governed Profiles;
governed Rule Sets;
governed Rules;
Validation Requests;
target versioning;
Executions;
Findings;
Receipts;
basic provenance.

70.2. Level 2 — Governance-Aware

It additionally has:

Evidence Snapshots;
rights validation;
authority validation;
tenant and white-label validation;
lifecycle and bitemporal validation;
exceptions;
remediation;
signed or digest-verifiable Receipts;
Module and Component lineage.

70.3. Level 3 — Cross-Specification and Gate-Integrated

It additionally validates:

knowledge objects;
assertions;
mappings;
graph integrity;
retrieval and embeddings;
AI processing;
Change Candidates;
Decisions;
projections;
Publication readiness;
certification boundaries;
Gate outcomes;
downstream receipt status.

70.4. Level 4 — Historically Assured

It additionally has:

deterministic or fully disclosed assisted execution;
immutable Snapshots;
historical Rule and Profile preservation;
Exact Replay;
Receipt Verification Replay;
drift controls;
Incident revocation;
independent assurance;
complete historical provenance;
no blocking Findings.

Level 4 SHALL NOT imply legal, semantic, certification, Publication or Runtime authority.

71. Conformance Fixtures

Implementations SHOULD provide fixtures for:

valid Conformance Profile;
Profile without purpose;
Profile with unresolved Rule Set;
Profile with invalid severity override;
immutable executed Profile;
valid Rule Set;
cyclic Rule Set composition;
valid deterministic Rule;
Rule without source authority;
Rule implementation digest mismatch;
model-assisted Rule without Model Profile;
not-applicable Rule;
unable-to-determine Rule;
blocking dependency failure;
fail-fast execution with unreported Rules;
positive Rule fixture;
negative Rule fixture;
boundary fixture;
tenant-isolation fixture;
Golden Receipt regression;
valid Validation Request;
Request with target-digest drift;
unbounded Request;
missing target;
ambiguous target;
complete Evidence Snapshot;
incomplete Snapshot;
restricted Snapshot;
deterministic Execution Plan;
valid Validation Execution;
timed-out Execution;
resource-exhausted Execution;
execution-environment drift;
explicit passed Rule result;
failed Rule result;
warning result;
not-executed result;
blocked result;
validator error;
valid Finding;
Finding without reproducible evidence;
duplicate Finding grouping;
false-positive Decision;
valid Gate pass;
Gate pass with warnings;
Gate failure;
Gate unable to determine;
valid signed Conformance Receipt;
Receipt without target digest;
expired Receipt;
revoked Receipt;
invalid signature;
public verification with redacted evidence;
valid temporary exception;
exception without authority;
exception broader than target;
expired exception;
prohibited constitutional waiver;
emergency waiver;
compensating control;
failed compensating control;
valid Remediation Plan;
deterministic auto-fix candidate;
silent object mutation attempt;
full revalidation;
permitted partial revalidation;
invalid partial revalidation;
valid Baseline;
Baseline drift;
schema-valid object;
unknown prohibited field;
unauthorised schema default;
identifier collision;
retired identifier reuse;
invalid lifecycle transition;
invalid superseded-active overlap;
valid bitemporal object;
invalid interval;
retroactively recorded object;
temporal conflict;
complete provenance;
circular provenance;
controlled redaction;
valid Rights Record;
missing permission basis;
most-restrictive-rights application;
unresolved legal ownership;
authority escalation;
Runtime authority without Activation Record;
cross-tenant reference;
white-label leakage;
global promotion without Decision;
orphan Component lineage;
valid Knowledge Object;
Source Object and Capture conflation;
Knowledge Document and Entity conflation;
valid relationship;
dangling relationship;
cardinality violation;
invalid transitivity;
historical graph validation;
valid Knowledge Assertion;
assertion without Source Fragment;
AI assertion without support;
invalid predicate;
quantity with incompatible unit;
formula dimensional error;
certification assertion outside scope;
valid Mapping Object;
exact-equivalence mapping without evidence;
Crosswalk completeness gap;
invalid mapping composition;
valid citation;
fabricated citation;
excessive quotation;
missing attribution;
valid Retrieval Eligibility Record;
prohibited embedding operation;
expired retrieval eligibility;
valid chunk;
chunk without exact lineage;
wrong embedding dimensions;
mixed incompatible embedding spaces;
deleted embedding in active index;
valid Retrieval Session;
cross-tenant Retrieval Result;
invalid Context Package digest;
Context Package token overflow;
valid AI Processing Task;
model not approved for Task;
provider-training policy violation;
unauthorised Tool Invocation;
invalid structured output;
ungrounded high-impact claim;
fabricated AI citation;
missing human review;
valid Change Candidate;
target drift;
hidden Candidate change;
secret in Candidate;
destructive Candidate without rollback;
cyclic Candidate dependency;
valid Change Decision;
Decision payload mismatch;
expired Decision;
unsatisfied blocking condition;
valid Projection Manifest;
projection without Decision;
unpinned production input;
Generated Artefact digest mismatch;
non-reproducible deterministic build;
released artefact incorrectly reported active;
activation digest mismatch;
valid Publication Package;
Publication without approval;
withdrawn source in Publication;
valid certification-support package;
certificate outside scope;
security dependency-integrity failure;
personal-data retention expiry;
exact historical validation;
current-rule reassessment of historical object;
valid model-assisted candidate Finding;
model-assisted output incorrectly treated deterministic;
valid human Attestation;
expired Attestation;
degraded HECATE mode;
unavailable required Rule Registry;
stale validation cache;
undeclared Rule drift;
false-pass Incident;
signing-key compromise;
complete audit;
Exact Replay;
Receipt Verification Replay;
historical digest mismatch;
complete Level 4 conformance package.

72. Migration and Compatibility

Profile revisions SHALL identify:

source Profile version;
target Profile version;
changed object fields;
changed Rule classes;
changed Finding codes;
changed severity policy;
changed Gate policy;
changed Receipt fields;
changed exception policy;
changed historical-replay requirements;
migration Rules;
compatibility;
affected Profiles;
affected Rule Sets;
affected Rules;
affected Receipts;
affected exceptions;
affected baselines;
validation;
provenance.

Migration SHALL NOT:

reuse object identifiers;
overwrite historical Profiles or Rules;
rewrite issued Findings;
rewrite issued Receipts;
infer missing evidence;
infer authority;
infer rights;
convert unable_to_determine to passed;
convert not_executed to passed;
conceal failed Rules;
suppress Findings;
silently reduce severity;
silently widen exception scope;
treat current Rules as historical Rules;
create Runtime authority.

72.1. Rule Migration

Rule migration SHALL preserve:

old Rule identity and version;
new Rule identity and version;
semantic difference;
severity difference;
affected Profiles;
fixture results;
retrospective policy;
provenance.

72.2. Finding-Code Migration

A Finding-code migration SHALL preserve historical resolvability.

72.3. Receipt-Schema Migration

Receipt migration SHALL preserve original signed payloads and SHALL create a derived representation rather than rewriting the original Receipt.

72.4. Legacy Validation Import

Legacy validation records MAY be imported only with:

source record;
best-available target identity;
Rule or criterion identity;
outcome;
limitations;
confidence;
historical classification;
provenance.

Legacy records SHALL not be represented as fully conformant without evidence.

73. Conformance Package

A high-impact validation MAY produce a Conformance Package containing:

Validation Request;
Evidence Snapshot;
Conformance Profile;
Rule Sets;
Execution Plan;
Validation Execution;
Findings;
Conformance Receipt;
signatures;
attestations;
exceptions;
Remediation Plan;
audit references;
public verification metadata;
provenance.

73.1. Package Identity

A Package SHALL possess a stable identity and version.

73.2. Package Digest

The Package SHOULD have a digest covering all included immutable objects.

73.3. Package Redaction

A redacted Package SHALL preserve:

redacted-object placeholders;
redaction authority;
redaction reason;
integrity relationship;
access path for authorised reviewers.

73.4. Package Portability

Portable Packages SHOULD use documented open formats and preserve signatures, digests and identifiers.

73.5. Package Non-Authority

A Conformance Package does not create authority beyond its constituent Decisions and governing frameworks.

74. Conformance Requirements

An implementation conforms to this Profile where it:

treats HECATE as a validation Component rather than a truth or authority source;
prevents HECATE from creating legal, semantic, rights, certification, Publication or Runtime authority;
distinguishes structural validity, governance completeness, eligibility, Decision, projection, release and activation;
represents Conformance Profiles as stable versioned objects;
binds every Profile to a declared purpose;
identifies target classes, Rule Sets, gates, evidence, expiry, scope and owner;
preserves immutable executed Profile versions;
prevents Profile execution from granting authority;
represents Rule Sets as stable versioned objects;
preserves Rule ordering, dependencies, parallelisation and fail-fast policy;
prevents cyclic Rule Set composition;
represents Validation Rules as stable versioned objects;
identifies Rule class, target class, criterion, inputs, expected result, Finding code and severity;
links every Rule to an approved source authority;
prevents Rules from silently inventing semantic or legal policy;
distinguishes deterministic, graph, statistical, heuristic, model-assisted, human-attested and informational Rules;
discloses model, threshold, calibration and review requirements for assisted Rules;
preserves immutable Rule versions used in Receipts;
represents Rule applicability explicitly;
returns not_applicable rather than pass where a Rule does not apply;
returns unable_to_determine where evidence cannot determine applicability;
prevents Rule scope from being generalised without approved change;
represents Rule dependencies and versions;
detects dependency cycles;
returns blocked where a required dependency is missing;
preserves degraded behaviour for optional dependencies;
reports every Rule omitted by fail-fast execution;
pins expression languages and executable implementations;
preserves implementation digests or source revisions;
executes Rules in least-privileged environments;
prevents validation Rules from producing unauthorised side effects;
governs external calls and mutable external evidence;
prevents secrets from entering Rules;
maintains positive, negative, boundary and missing-input fixtures for material Rules;
preserves fixture identities, versions and expected outcomes;
regression-tests Rule implementation changes;
protects fixture rights and privacy;
defines informational, low, moderate, high, critical and constitutional severity;
derives severity from approved Rules or Profiles;
makes dynamic severity escalation deterministic and auditable;
prevents execution-time unauthorised severity reduction;
assigns stable governed Finding codes;
prevents Finding-code reuse;
preserves deprecated Finding-code resolvability;
represents every material validation through a Validation Request;
preserves requester, purpose, targets, versions, digests, Profile, time, tenant and environment;
binds validation to the declared purpose;
detects target mutation after Request creation;
prohibits unbounded validation over unspecified scope;
resolves targets to stable identities, versions, digests, lifecycle, scope, owner, Module and Component;
fails missing or ambiguous required targets;
distinguishes canonical targets from derived copies;
preserves multi-target membership and graph closure;
creates immutable Evidence Snapshots;
includes target, schema, Registry, rights, policy, graph, tenant and temporal dependencies in Snapshots;
preserves Snapshot digests;
represents Snapshot completeness explicitly;
prevents materially incomplete Snapshots from producing definitive pass;
protects restricted evidence throughout validation;
creates versioned Execution Plans;
resolves exact Profiles, Rule Sets, Rules and dependency order;
preserves timeouts, retries, resource limits and execution environment;
makes Plans deterministic where feasible;
preserves immutable executed Plans;
creates a Validation Execution record for every run and retry;
pins HECATE Component, build, container, dependency and configuration versions;
preserves execution isolation and least privilege;
logs enough for audit without exposing restricted content;
prevents resource exhaustion from producing pass;
produces an explicit result for every Rule;
distinguishes passed, failed, warning, informational, not applicable, not executed, blocked, unable to determine and error;
never silently converts a non-passed result into passed;
creates Findings for required non-passed outcomes;
assigns stable Finding identities and versions;
preserves Rule, target, object path, observed state, expected state, evidence, severity and remediation guidance;
prevents Finding identity from depending on message text;
preserves individual Findings when aggregating or deduplicating;
preserves immutable completed Findings;
governs Finding lifecycle;
preserves false-positive Decisions without rewriting original executions;
makes Finding evidence reproducible and minimised;
preserves evidence chains and rights;
aggregates Findings without erasing identity or high-severity impact;
evaluates purpose-specific Gates;
uses Rule results, severities, Findings, exceptions, attestations and Profile policy in Gate evaluation;
distinguishes pass, pass with warnings, conditional pass, fail, blocked, unable to determine, expired and revoked;
prevents Gate pass from issuing domain authority;
exposes the Rules and Findings determining Gate outcomes;
issues immutable Conformance Receipts;
preserves Request, Snapshot, Execution, Profile, target digests, Rule versions, outcome, Findings and limitations;
preserves Receipt scope by purpose, environment, tenant and time;
states what each Receipt does not prove;
expires Receipts after material target, dependency, Rule, Profile, rights, policy or environment change;
supports Receipt revocation and downstream impact analysis;
supports digest and signature verification;
governs signing keys, rotation and revocation;
treats signature or digest failure as critical;
supports privacy-preserving public Receipt verification;
represents exceptions and waivers as separate authority-bearing Decisions;
preserves exception scope, reason, authority, risk, conditions, time, expiry and prohibited uses;
prevents exception transitivity;
prohibits waiver where governing Rules disallow it;
governs emergency waivers through short expiry, compensating controls and retrospective review;
discloses exceptions in Receipts;
represents compensating controls and their evidence;
prevents compensating controls from being assumed equivalent without authority;
validates objective compensating-control operation without deciding disputed sufficiency;
creates versioned Remediation Plans;
preserves Findings, root cause, actions, owners, due dates, evidence and revalidation;
prevents HECATE from silently mutating targets;
routes deterministic auto-fixes through explicit correction candidates and change governance;
confirms remediation through new validation;
preserves prior failure history after successful revalidation;
limits partial revalidation to deterministically identified unaffected dependencies;
requires full revalidation after material changes and incidents;
represents immutable HECATE Baselines;
uses Baselines for drift, audit and historical comparison without creating authority;
validates structural and schema conformance with pinned schema versions;
governs unknown fields and defaults;
prevents silent schema repair;
validates identity prefix, uniqueness, immutability, non-reuse, semantic identifiers and tombstones;
fails identifier collisions and retired-identifier reuse;
validates permitted lifecycle states and transitions;
preserves supersession, withdrawal and deletion history;
validates bitemporal intervals, timezone, precision and retroactive recording;
preserves temporal conflicts rather than silently resolving them;
validates provenance graphs and completeness;
blocks high-impact actions where provenance is materially incomplete;
validates Rights Record structure, scope, validity, processing rights, Publication rights and attribution;
treats unknown or omitted permission as not granted;
applies the most-restrictive applicable rights rule where deterministic;
prevents HECATE from deciding disputed copyright or fair-use issues;
validates rights revocation propagation;
validates separate authority dimensions;
detects authority escalation;
fails Runtime authority without Activation Record;
prevents targets from treating a HECATE pass as semantic or legal authority;
validates tenant and white-label identities and boundaries;
treats unauthorised cross-tenant or white-label references as critical;
validates global-promotion Decisions;
validates both Module and Component lineage;
fails orphan Component lineage for material execution-affecting objects;
validates universal Knowledge Object contracts;
preserves separation among Source Series, Source Object, Source Capture, Knowledge Document and Knowledge Entity;
preserves separation between Source Fragment and Knowledge Assertion;
validates relationship type, direction, inverse, symmetry, transitivity, cardinality, scope and provenance;
fails dangling relationships, invalid cycles and invalid transitivity;
validates rights-aware and historical graphs;
validates PP-KAS assertion identity, subject, predicate, object, evidence, authority, applicability, confidence, time and review;
fails source-supported assertions without exact Source Fragment evidence;
prevents unsupported AI assertions from passing source-supported admission;
validates null semantics, quantities, units, thresholds and formula structure;
prevents HECATE from deciding disputed methodology validity;
validates PP-SMCS mapping identity, source, target, type, direction, cardinality, evidence, scope, confidence, coverage and conflicts;
prevents HECATE from deciding semantic, legal or certification equivalence;
fails unsupported exact-equivalence claims;
includes no-map and gap objects in Crosswalk completeness;
validates mapping composition without assuming transitivity;
validates PP-RLCPS citations, locators, attribution, quotation limits and Publication Packages;
fails unresolved or fabricated citation targets;
prevents Publication readiness validation from approving Publication;
validates PP-REAPP Retrieval Eligibility Records;
blocks prohibited or expired chunking, embedding, RAG and external-processing operations;
validates chunks, exact lineage, digests, Profiles, rights and scope;
validates embeddings, model versions, dimensions, indexes and deletion state;
prevents incompatible embedding spaces from mixing without an approved method;
validates Retrieval Requests, Plans, filters, Sessions, Results and Context Packages;
treats cross-tenant Retrieval Results as critical;
validates context digests, Prompt Profiles and token budgets;
validates AI Processing Tasks, Model Profiles, Inference Records, tools, outputs, grounding and citations;
prevents unapproved models, providers and tools from passing;
requires schema-valid machine-actionable AI output;
blocks ungrounded high-impact claims where required;
prevents model output from satisfying human-authority Rules;
validates PP-CCPS Candidates, source basis, target pinning, operation, impact, dependencies, risk and conflicts;
fails target drift, hidden changes, secrets, unsupported destructive changes and dependency cycles;
validates Change Decisions, Candidate versions, payload digests, authority, conditions and expiry;
prevents expired, mismatched or condition-incomplete Decisions from authorising projection;
validates Projection Manifests, pinned inputs, compiler versions, artefacts, digests, receipts and scope;
fails projections without applicable Change Decisions;
fails unpinned mutable production inputs;
validates deterministic-build expectations and cross-artefact consistency;
distinguishes projection, release and activation;
fails activation digest drift;
validates objective Runtime admission preconditions without performing activation;
validates Publication readiness without issuing Publication approval;
validates certification-support evidence without issuing certification;
validates security metadata, signatures, build integrity and secrets controls;
validates objective privacy and retention metadata without making disputed legal determinations;
supports historical validation using historical Rules, Profiles, schemas, Registries and rights;
distinguishes exact historical validation from current-rule reassessment;
prevents retroactive silent substitution of current Rules;
governs model-assisted validation as candidate or heuristic output;
requires Model Profiles, Prompt Profiles, evaluation and review for assisted Rules;
prevents model-assisted outputs from masquerading as deterministic failures;
represents human and organisational Attestations as separate signed objects;
validates Attestation identity, competence, scope and expiry;
prevents Attestation from substituting for required objective evidence;
operates HECATE as a governed production validation service;
preserves security and rights in degraded mode;
blocks validation when required Rule or Profile sources are unavailable;
supports resilient backup and recovery with integrity validation;
prevents performance controls and caches from producing stale or incomplete passes;
governs Rule and Profile changes through change control;
treats severity changes as material;
supports canary and shadow Rule deployment without hidden gating;
detects Rule, Profile, schema, Registry, implementation, environment and model drift;
invalidates trust after undeclared gating-Rule implementation drift;
manages false-pass, false-failure, key-compromise, leakage and bypass Incidents;
preserves Incident evidence and revokes affected Receipts where required;
logs material lifecycle events with correlation and tamper evidence;
subjects HECATE itself to assurance and audit;
preserves historical Requests, Snapshots, Rules, Findings, exceptions and Receipts;
supports Receipt Verification Replay and Rule Re-Execution Replay;
discloses historical reproducibility limitations;
defines four conformance levels;
supports comprehensive conformance fixtures;
governs migration without rewriting historical objects;
imports legacy validation records only with explicit limitations;
supports portable, digest-verifiable Conformance Packages;
preserves redaction integrity in Conformance Packages;
never interprets a passing HECATE Receipt as proof of truth, legal correctness, semantic adoption, certification, Publication approval or active Runtime state.

75. Foundational Principle

HECATE SHALL make conformance visible, reproducible and governable without becoming the authority that defines truth.

A schema-valid object may still be semantically wrong. A governance-complete object may still lack authority. A rights-complete object may still be inapplicable. A passing Rule may still be insufficient for admission. A passing Gate may still require an authorised Decision. A released artefact may still be inactive.

HECATE SHALL therefore validate only against identified Rules, Profiles, evidence and versions. It SHALL preserve every non-pass state, every Finding, every exception, every limitation and every historical dependency. It SHALL never silently repair the target, suppress conflict, invent evidence, infer permission or absorb the authority of reviewers, legal owners, certification bodies, Publication authorities or Runtime admission authorities.

Rules define criteria. HECATE executes them. Findings expose deviation. Receipts record outcomes. Human and organisational authorities decide what those outcomes permit. Separate systems project, publish, certify or activate.

By governing validation through immutable Profiles, versioned Rules, evidence snapshots, deterministic execution, signed receipts, scoped exceptions, remediation, tenant isolation and historical replay, HECATE becomes the assurance spine of Pergamum Pulse while preserving constitutional authority, legal defensibility, operational safety and complete historical trust.

GitHub Repo Request for Change (RFC)

Version 0.1 — Normative Knowledge Validation and Conformance Contract
1. Scope
2. Normative Language
3. HECATE Role and Authority Boundary
- 3.1. Validation Versus Authority
- 3.2. Rule Authority
- 3.3. Finding Authority
- 3.4. Receipt Boundary
4. Conformance Architecture
5. Canonical HECATE Objects
6. HECATE Conformance Profile
- 6.1. Required Profile Fields
- 6.2. Profile Purpose
- 6.3. Profile Versioning
- 6.4. Profile Immutability
- 6.5. Profile Non-Authority
7. HECATE Rule Set
- 7.1. Required Rule Set Fields
- 7.2. Rule Set Classes
- 7.3. Rule Set Composition
- 7.4. Rule Set Drift
8. HECATE Validation Rule
- 8.1. Required Rule Fields
- 8.2. Rule Classes
- 8.3. Objective Criterion
- 8.4. Assisted Criterion
- 8.5. Rule Source Authority
- 8.6. Rule Non-Invention
- 8.7. Rule Versioning
- 8.8. Rule Immutability
9. Rule Applicability
- 9.1. Non-Applicable Rule
- 9.2. Unable to Determine
- 9.3. Applicability Evidence
- 9.4. Scope Generalisation Prohibition
10. Rule Dependency and Ordering
- 10.1. Dependency Declaration
- 10.2. Dependency Graph
- 10.3. Blocking Dependency
- 10.4. Optional Dependency
- 10.5. Rule Ordering
- 10.6. Fail-Fast
11. Rule Expression and Implementation
- 11.1. Expression Language
- 11.2. Implementation Digest
- 11.3. Sandboxing
- 11.4. Side Effects
- 11.5. External Calls
- 11.6. Non-Deterministic Data Source
- 11.7. Secret Handling
12. Rule Test Fixtures
- 12.1. Fixture Identity
- 12.2. Expected Outcome
- 12.3. Fixture Regression
- 12.4. Golden Receipt
- 12.5. Fixture Rights
13. Severity Model
- 13.1. Informational
- 13.2. Low
- 13.3. Moderate
- 13.4. High
- 13.5. Critical
- 13.6. Constitutional
- 13.7. Severity Authority
- 13.8. Dynamic Escalation
- 13.9. Severity Reduction
14. Finding Codes
- 14.1. Code Registry
- 14.2. Code Stability
- 14.3. Deprecated Code
15. Validation Request
- 15.1. Required Request Fields
- 15.2. Requester Classes
- 15.3. Purpose Binding
- 15.4. Target Mutation
- 15.5. Unbounded Validation
16. Target Resolution
- 16.1. Missing Target
- 16.2. Ambiguous Target
- 16.3. Derived Copy
- 16.4. Target Set
- 16.5. Target Graph Closure
17. HECATE Evidence Snapshot
- 17.1. Required Snapshot Fields
- 17.2. Snapshot Immutability
- 17.3. Snapshot Completeness
- 17.4. Incomplete Snapshot
- 17.5. Restricted Evidence
18. HECATE Execution Plan
- 18.1. Required Plan Fields
- 18.2. Plan Determinism
- 18.3. Plan Review
- 18.4. Plan Immutability
19. HECATE Validation Execution
- 19.1. Execution Status
- 19.2. Execution Identity
- 19.3. Environment Pinning
- 19.4. Execution Isolation
- 19.5. Execution Logs
- 19.6. Resource Exhaustion
20. Rule Execution Result
- 20.1. Passed
- 20.2. Failed
- 20.3. Warning
- 20.4. Not Applicable
- 20.5. Not Executed
- 20.6. Blocked
- 20.7. Unable to Determine
- 20.8. Error
- 20.9. No Silent Pass
21. Finding Object
- 21.1. Required Finding Fields
- 21.2. Finding Identity
- 21.3. Finding Deduplication
- 21.4. Finding Immutability
- 21.5. Finding Lifecycle
- 21.6. False Positive
22. Finding Evidence
- 22.1. Evidence Redaction
- 22.2. Evidence Sufficiency
- 22.3. Evidence Chain
- 22.4. Evidence Rights
23. Finding Aggregation
- 23.1. Aggregation Non-Erasure
- 23.2. Count Semantics
- 23.3. Severity Aggregation
- 23.4. Trend Analysis
24. Gate Evaluation
- 24.1. Gate Types
- 24.2. Gate Inputs
- 24.3. Gate Outcomes
- 24.4. Gate Non-Authority
- 24.5. Gate Transparency
25. Conformance Receipt
- 25.1. Required Receipt Fields
- 25.2. Receipt Immutability
- 25.3. Receipt Scope
- 25.4. Receipt Limitations
- 25.5. Receipt Expiry
- 25.6. Receipt Revocation
- 25.7. Receipt Verification
26. Receipt Signing and Verification
- 26.1. Signature Metadata
- 26.2. Key Governance
- 26.3. Detached Signature
- 26.4. Verification Failure
- 26.5. Public Verification
27. Exception and Waiver Governance
- 27.1. Required Exception Fields
- 27.2. Exception Classes
- 27.3. Exception Scope
- 27.4. Exception Non-Transitivity
- 27.5. Exception Expiry
- 27.6. Critical and Constitutional Rules
- 27.7. Emergency Waiver
- 27.8. Waiver Visibility
28. Compensating Controls
- 28.1. Effectiveness Validation
- 28.2. Effectiveness Decision
- 28.3. Control Failure
29. Remediation Plan
- 29.1. Required Remediation Fields
- 29.2. Remediation States
- 29.3. Remediation Non-Mutation
- 29.4. Auto-Fix Candidate
- 29.5. Revalidation
30. Revalidation
- 30.1. Prior Receipt Linkage
- 30.2. Partial Revalidation
- 30.3. Full Revalidation Triggers
- 30.4. Pass After Remediation
31. HECATE Baseline
- 31.1. Baseline Uses
- 31.2. Baseline Immutability
- 31.3. Baseline Non-Authority
- 31.4. Baseline Drift
32. Structural and Schema Conformance
- 32.1. Schema Pinning
- 32.2. Unknown Fields
- 32.3. Default Values
- 32.4. Schema Repair
- 32.5. Multiple Schemas
33. Identity Conformance
- 33.1. Collision
- 33.2. Retired Identifier
- 33.3. Storage-Path Independence
- 33.4. Semantic Identifier
- 33.5. Alias Non-Identity
34. Lifecycle Conformance
- 34.1. Invalid Transition
- 34.2. Missing Transition Receipt
- 34.3. Superseded Active Object
- 34.4. Withdrawal Propagation
35. Bitemporal Conformance
- 35.1. Valid-Time Logic
- 35.2. Transaction-Time Logic
- 35.3. Retroactive Recording
- 35.4. Temporal Conflict
- 35.5. Current-State Query
36. Provenance Conformance
- 36.1. Provenance Graph Integrity
- 36.2. Provenance Completeness State
- 36.3. Materially Incomplete Provenance
- 36.4. Controlled Redaction
- 36.5. Circular Provenance
37. Rights Conformance
- 37.1. Unknown Permission
- 37.2. Most-Restrictive Rule
- 37.3. Rights Legal Judgement
- 37.4. Rights Gate
- 37.5. Revocation Propagation
38. Authority Conformance
- 38.1. Authority Dimensions
- 38.2. Authority Escalation
- 38.3. Runtime Authority
- 38.4. HECATE Authority
39. Tenant and White-Label Conformance
- 39.1. Cross-Tenant Reference
- 39.2. White-Label Leakage
- 39.3. Global Promotion
- 39.4. Scope Narrowing
- 39.5. Shared Infrastructure
40. Module and Component Lineage Conformance
- 40.1. Orphan Component
- 40.2. Invalid Module Membership
- 40.3. Lineage Preservation
- 40.4. Pergamum Pulse Requirement
41. Knowledge Object Conformance
- 41.1. Object-Class Contract
- 41.2. Object Version
- 41.3. Bundle Non-Aggregation
- 41.4. Source Separation
- 41.5. Fragment Separation
42. Relationship and Graph Conformance
- 42.1. Relationship Type Registry
- 42.2. Dangling Relationship
- 42.3. Cardinality Violation
- 42.4. Invalid Transitivity
- 42.5. Invalid Cycle
- 42.6. Rights-Aware Graph
- 42.7. Historical Graph
43. Knowledge Assertion Conformance
- 43.1. Source Evidence
- 43.2. Unsupported AI Assertion
- 43.3. Predicate Validity
- 43.4. Null Semantics
- 43.5. Quantitative Assertion
- 43.6. Formula Assertion
- 43.7. Certification Assertion
44. Mapping and Crosswalk Conformance
- 44.1. Equivalence Structure
- 44.2. Exact Equivalence Claim
- 44.3. No-Mapping and Gaps
- 44.4. Mapping Composition
- 44.5. Coverage
- 44.6. Mapping Conflict
45. Citation and Publication-Rights Conformance
- 45.1. Fabricated Citation
- 45.2. Quotation Rights
- 45.3. Attribution
- 45.4. Publication Non-Authority
- 45.5. Withdrawal Status
46. Retrieval Eligibility Conformance
- 46.1. No Eligibility Record
- 46.2. Prohibited Operation
- 46.3. Expired Eligibility
- 46.4. Purpose Mismatch
47. Chunk and Embedding Conformance
- 47.1. Chunk Lineage
- 47.2. Formula or Table Split
- 47.3. Embedding Dimension
- 47.4. Mixed Embedding Space
- 47.5. Deleted Embedding
- 47.6. Rights Propagation
48. Retrieval Session and Context Conformance
- 48.1. Pre-Exposure Filtering
- 48.2. Cross-Tenant Result
- 48.3. Context Digest
- 48.4. Omitted Conflict
- 48.5. Token Overflow
- 48.6. Prompt Profile Resolution
49. AI Processing Conformance
- 49.1. Model Eligibility
- 49.2. Provider Policy
- 49.3. Tool Permission
- 49.4. Structured Output
- 49.5. Grounding Completeness
- 49.6. Citation Resolution
- 49.7. Prompt Injection
- 49.8. Review Requirement
- 49.9. AI Non-Authority
50. Change Candidate Conformance
- 50.1. Unsupported Candidate
- 50.2. Target Drift
- 50.3. Hidden Change
- 50.4. Secret Detection
- 50.5. Destructive Change
- 50.6. Dependency Cycle
- 50.7. Candidate Conflict
51. Change Decision Conformance
- 51.1. Decision Mismatch
- 51.2. Expired Decision
- 51.3. Unsatisfied Condition
- 51.4. Decision Authority
- 51.5. Decision Immutability
52. Projection Conformance
- 52.1. Missing Decision
- 52.2. Unpinned Input
- 52.3. Artefact Digest
- 52.4. Deterministic Build
- 52.5. Cross-Artefact Consistency
- 52.6. Release Versus Activation
- 52.7. Activation Digest
53. Runtime Admission Boundary
- 53.1. Activation Non-Execution
- 53.2. Partial Activation
- 53.3. Activation Drift
- 53.4. Rollback State
54. Publication Readiness Boundary
- 54.1. Publication Approval
- 54.2. Claim Support
- 54.3. Current Source Status
- 54.4. Public Verification
55. Certification and Assurance Boundary
- 55.1. Scheme Rule Source
- 55.2. Evidence Scope
- 55.3. Certificate Validity
56. Security Conformance
- 56.1. Security Rule Authority
- 56.2. Secret Handling
- 56.3. Supply-Chain Validation
- 56.4. Vulnerability Judgement
57. Privacy and Personal-Data Conformance
- 57.1. Special Categories
- 57.2. Retention
- 57.3. Data Subject Requests
58. Historical Conformance
- 58.1. Exact Historical Validation
- 58.2. Current-Rule Reassessment
- 58.3. Non-Retroactivity
- 58.4. Historical Exception
- 58.5. Historical Receipt Status
59. Model-Assisted Validation
- 59.1. Assisted Result Classification
- 59.2. Model Profile
- 59.3. Human Review
- 59.4. Provider Restrictions
- 59.5. Drift
60. Human Attestation
- 60.1. Required Attestation Fields
- 60.2. Attestation Verification
- 60.3. Attestation Non-Substitution
- 60.4. Revocation
61. HECATE Operational Governance
- 61.1. Service States
- 61.2. Degraded Mode
- 61.3. Rule Registry Availability
- 61.4. Time Source
- 61.5. Locale and Encoding
62. Availability, Resilience and Recovery
- 62.1. Recovery Integrity
- 62.2. Backup Rights
- 62.3. Recovery Non-Reinterpretation
- 62.4. Disaster Recovery Test
63. Performance and Resource Governance
- 63.1. Performance Non-Bypass
- 63.2. Partial Execution
- 63.3. Prioritisation
- 63.4. Caching
- 63.5. Cache Invalidation
64. Rule and Profile Change Governance
- 64.1. Severity Change
- 64.2. Retrospective Effect
- 64.3. Emergency Rule
- 64.4. Canary Rule Deployment
- 64.5. Shadow Findings
65. Drift Detection
- 65.1. Drift Record
- 65.2. Undeclared Drift
- 65.3. Model-Assisted Drift
- 65.4. Environment Drift
66. HECATE Incident Management
- 66.1. False Pass
- 66.2. False Failure
- 66.3. Key Compromise
- 66.4. Evidence Preservation
67. Observability and Audit Logging
- 67.1. Correlation
- 67.2. Sensitive Logging
- 67.3. Tamper Evidence
- 67.4. Log Retention
- 67.5. Log Access
68. Assurance and Audit
- 68.1. Audit Record
- 68.2. Rule Sampling
- 68.3. Independent Validation
- 68.4. Assurance Non-Certification
69. Historical Validation Replay
- 69.1. Exact Replay
- 69.2. Receipt Verification Replay
- 69.3. Rule Re-Execution Replay
- 69.4. Current-Baseline Reassessment
- 69.5. Reproducibility Limitation
- 69.6. Digest Mismatch
70. Conformance Levels
- 70.1. Level 1 — Structurally Validated
- 70.2. Level 2 — Governance-Aware
- 70.3. Level 3 — Cross-Specification and Gate-Integrated
- 70.4. Level 4 — Historically Assured
71. Conformance Fixtures
72. Migration and Compatibility
- 72.1. Rule Migration
- 72.2. Finding-Code Migration
- 72.3. Receipt-Schema Migration
- 72.4. Legacy Validation Import
73. Conformance Package
- 73.1. Package Identity
- 73.2. Package Digest
- 73.3. Package Redaction
- 73.4. Package Portability
- 73.5. Package Non-Authority
74. Conformance Requirements
75. Foundational Principle

Version 0.1 — Normative Knowledge Validation and Conformance Contract​

1. Scope​

2. Normative Language​

3. HECATE Role and Authority Boundary​

3.1. Validation Versus Authority​

3.2. Rule Authority​

3.3. Finding Authority​

3.4. Receipt Boundary​

4. Conformance Architecture​

5. Canonical HECATE Objects​

6. HECATE Conformance Profile​

6.1. Required Profile Fields​

6.2. Profile Purpose​

6.3. Profile Versioning​

6.4. Profile Immutability​

6.5. Profile Non-Authority​

7. HECATE Rule Set​

7.1. Required Rule Set Fields​

7.2. Rule Set Classes​

7.3. Rule Set Composition​

7.4. Rule Set Drift​

8. HECATE Validation Rule​

8.1. Required Rule Fields​

8.2. Rule Classes​

8.3. Objective Criterion​

8.4. Assisted Criterion​

8.5. Rule Source Authority​

8.6. Rule Non-Invention​

8.7. Rule Versioning​

8.8. Rule Immutability​

9. Rule Applicability​

9.1. Non-Applicable Rule​

9.2. Unable to Determine​

9.3. Applicability Evidence​

9.4. Scope Generalisation Prohibition​

10. Rule Dependency and Ordering​

10.1. Dependency Declaration​

10.2. Dependency Graph​

10.3. Blocking Dependency​

10.4. Optional Dependency​

10.5. Rule Ordering​

10.6. Fail-Fast​

11. Rule Expression and Implementation​

11.1. Expression Language​

11.2. Implementation Digest​

11.3. Sandboxing​

11.4. Side Effects​

11.5. External Calls​

11.6. Non-Deterministic Data Source​

11.7. Secret Handling​

12. Rule Test Fixtures​

12.1. Fixture Identity​

12.2. Expected Outcome​

12.3. Fixture Regression​

12.4. Golden Receipt​

12.5. Fixture Rights​

13. Severity Model​

13.1. Informational​

13.2. Low​

13.3. Moderate​

13.4. High​

13.5. Critical​

13.6. Constitutional​

13.7. Severity Authority​

13.8. Dynamic Escalation​

13.9. Severity Reduction​

14. Finding Codes​

14.1. Code Registry​

14.2. Code Stability​

14.3. Deprecated Code​

15. Validation Request​

15.1. Required Request Fields​

15.2. Requester Classes​

15.3. Purpose Binding​

15.4. Target Mutation​

15.5. Unbounded Validation​

16. Target Resolution​

16.1. Missing Target​

16.2. Ambiguous Target​

16.3. Derived Copy​

Version 0.1 — Normative Knowledge Validation and Conformance Contract

1. Scope

2. Normative Language

3. HECATE Role and Authority Boundary

3.1. Validation Versus Authority

3.2. Rule Authority

3.3. Finding Authority

3.4. Receipt Boundary

4. Conformance Architecture

5. Canonical HECATE Objects

6. HECATE Conformance Profile

6.1. Required Profile Fields

6.2. Profile Purpose

6.3. Profile Versioning

6.4. Profile Immutability

6.5. Profile Non-Authority

7. HECATE Rule Set

7.1. Required Rule Set Fields

7.2. Rule Set Classes

7.3. Rule Set Composition

7.4. Rule Set Drift

8. HECATE Validation Rule

8.1. Required Rule Fields

8.2. Rule Classes

8.3. Objective Criterion

8.4. Assisted Criterion

8.5. Rule Source Authority

8.6. Rule Non-Invention

8.7. Rule Versioning

8.8. Rule Immutability

9. Rule Applicability

9.1. Non-Applicable Rule

9.2. Unable to Determine

9.3. Applicability Evidence

9.4. Scope Generalisation Prohibition

10. Rule Dependency and Ordering

10.1. Dependency Declaration

10.2. Dependency Graph

10.3. Blocking Dependency

10.4. Optional Dependency

10.5. Rule Ordering

10.6. Fail-Fast

11. Rule Expression and Implementation

11.1. Expression Language

11.2. Implementation Digest

11.3. Sandboxing

11.4. Side Effects

11.5. External Calls

11.6. Non-Deterministic Data Source

11.7. Secret Handling

12. Rule Test Fixtures

12.1. Fixture Identity

12.2. Expected Outcome

12.3. Fixture Regression

12.4. Golden Receipt

12.5. Fixture Rights

13. Severity Model

13.1. Informational

13.2. Low

13.3. Moderate

13.4. High

13.5. Critical

13.6. Constitutional

13.7. Severity Authority

13.8. Dynamic Escalation

13.9. Severity Reduction

14. Finding Codes

14.1. Code Registry

14.2. Code Stability

14.3. Deprecated Code

15. Validation Request

15.1. Required Request Fields

15.2. Requester Classes

15.3. Purpose Binding

15.4. Target Mutation

15.5. Unbounded Validation

16. Target Resolution

16.1. Missing Target

16.2. Ambiguous Target

16.3. Derived Copy