Chapter 27 — Core Conformance and Certification Framework

Part II — Assessment Engineering, Evidence and Test Execution

Part II defines the operational assessment architecture through which the foundational objects established in Part I are converted into controlled, reproducible and reviewable conformance evidence.

Part I established:

the Core conformance boundary;
distinctions among validation, conformance, assurance, certification, accreditation, approval, Runtime Admission and Publication eligibility;
Conformance Subjects and Subject Snapshots;
Conformance Requirements;
Control Objectives;
Controls;
Criteria;
Test Specifications;
Evidence Objects;
Conformance Profiles;
Applicability Decisions;
Findings;
Exceptions;
Compensating Controls;
Remediation;
Conformance Outcomes;
assessment lifecycle foundations;
Certification Scheme foundations;
constitutional and Runtime integration.

Part II governs how assessments are engineered and executed.

It defines:

Conformance Assessment Programmes;
assessment portfolios;
assessment Charters;
subject discovery;
authoritative inventory;
scope manifests;
dependency discovery;
requirement traceability;
Control mapping;
coverage analysis;
evidence plans;
evidence acquisition;
Evidence Packages;
chain of custody;
test engineering;
conformance fixtures;
test oracles;
automated validation;
continuous conformance;
expert judgement;
inspection;
sampling;
materiality;
confidence;
uncertainty;
Finding adjudication;
root-cause and systemic analysis;
remediation;
reassessment;
closure;
Assessment Packages;
Assessment Reports;
decision-support artefacts;
Part II provenance.

The governing principles are:

Assessment design SHALL precede authoritative evidence interpretation.

The assessed subject, requirement set, applicability context, methods, evidence needs, sampling, materiality and outcome rules SHALL be fixed or governed before final assessment execution.

Subject discovery SHALL identify actual Modules, Components, Extensions, tenant overlays, white-label overlays, external dependencies and Runtime state. An incomplete inventory SHALL not be disguised as complete scope.

Requirement traceability SHALL connect every applicable requirement to its Control Objectives, Controls, Criteria, Tests, Evidence Objects, Findings and Outcomes.

Evidence acquisition SHALL be minimally invasive, integrity-protected, tenant-isolated, purpose-bound and historically reproducible.

A test oracle SHALL derive from governed meaning. Implementation behaviour, previous output or majority behaviour SHALL not become the oracle merely because it is available.

Automated validation SHALL be limited to criteria that can be evaluated objectively under the approved method. HECATE SHALL escalate unresolved judgement rather than manufacture certainty.

Sampling SHALL support bounded inference. A sample SHALL not create universal certainty beyond the population, period, confidence and limitations that govern it.

A Finding SHALL preserve the observed non-conformant state even after remediation. Closure SHALL add governed evidence; it SHALL not erase history.

An Assessment Package SHALL support a Conformance Outcome, assurance engagement or Certification Decision. It SHALL not make those decisions by presentation alone.

Every assessment path SHALL preserve Module lineage and Component lineage, together with Baseline, Runtime Bundle, Runtime Manifest, Extension, tenant, white-label, Publication and temporal lineage.

The Part II architecture is:

Assessment Portfolio
        │
        ▼
Conformance Assessment Programme
        │
        ├── Programme Charter
        ├── Assessment Requests
        ├── Independence Model
        ├── Competence Model
        ├── Risk Model
        └── Schedule
        │
        ▼
Subject Discovery and Scope Resolution
        │
        ├── Subject Inventory
        ├── Module Inventory
        ├── Component Inventory
        ├── Extension Inventory
        ├── Tenant and White-Label Inventory
        ├── Dependency Inventory
        └── Subject Snapshot
        │
        ▼
Requirement Traceability and Control Mapping
        │
        ├── Requirements
        ├── Control Objectives
        ├── Controls
        ├── Criteria
        ├── Tests
        └── Evidence Requirements
        │
        ▼
Evidence and Test Engineering
        │
        ├── Evidence Plan
        ├── Evidence Acquisition
        ├── Evidence Package
        ├── Test Suite
        ├── Fixtures
        ├── Oracles
        └── Environments
        │
        ▼
Assessment Execution
        │
        ├── Automated Validation
        ├── Manual Inspection
        ├── Reperformance
        ├── Sampling
        ├── Replay
        └── Expert Judgement
        │
        ▼
Findings, Root Cause and Remediation
        │
        ▼
Assessment Package and Decision Support

Part II SHALL remain independent of any one test runner, continuous-integration platform, GRC application, evidence repository, policy engine, graph database, sampling application, ticketing system, security scanner, AI model, audit platform or reporting system.

27.13. Conformance Assessment Programmes and Portfolio Governance

A Conformance Assessment Programme coordinates one or more related assessments across subjects, Baselines, Profiles, tenants, white-label deployments, Modules, Components, Extensions, environments or periods.

A Programme SHALL preserve the independent identity, scope and Outcome of each assessment while governing shared resources, common Controls, evidence and dependencies.

27.13.1. Assessment Programme Identity

Every Assessment Programme SHALL possess:

Assessment Programme Identifier;
canonical name;
Programme Charter;
Programme owner;
sponsor;
assessment purpose;
subject classes;
governing Constitutional Baselines;
Conformance Profiles;
Certification Schemes where applicable;
included assessments;
affected tenants and white-label deployments;
affected Modules;
affected Components;
affected Extensions;
jurisdictions;
schedule;
resource profile;
independence model;
competence model;
risk profile;
lifecycle;
version;
provenance.

27.13.2. Programme Types

Programme Types MAY include:

Core Baseline Conformance Programme;
Runtime Conformance Programme;
Module Conformance Programme;
Component Conformance Programme;
Extension Conformance Programme;
Tenant Conformance Programme;
White-Label Conformance Programme;
Organisation Conformance Programme;
Publication Conformance Programme;
Security Conformance Programme;
Tenant-Isolation Conformance Programme;
Migration Conformance Programme;
Certification Assessment Programme;
Continuous Conformance Programme;
Historical Conformance Programme;
Incident-Triggered Assessment Programme.

27.13.3. Programme Charter

The Programme Charter SHALL define:

purpose;
authority;
constitutional and business objective;
subject population;
included Baselines;
included Profiles;
included Schemes;
jurisdictions;
assessment cadence;
risk approach;
materiality approach;
independence;
competence;
evidence strategy;
test strategy;
sampling strategy;
reporting;
escalation;
success criteria;
stop conditions;
provenance.

27.13.4. Assessment Portfolio

An Assessment Portfolio is the governed inventory of:

requested assessments;
admitted assessments;
planned assessments;
active assessments;
suspended assessments;
completed assessments;
assessments under remediation;
surveillance assessments;
recertification assessments;
historical assessments;
cancelled assessments.

27.13.5. Portfolio Entry

Every Portfolio Entry SHALL identify:

assessment;
Programme;
subject;
Baseline;
Profile;
purpose;
owner;
sponsor;
assessor;
status;
risk;
target dates;
dependencies;
certification relationship;
provenance.

27.13.6. Programme Prioritisation

Prioritisation MAY consider:

Protected Invariant impact;
legal or regulatory deadline;
security risk;
tenant-isolation risk;
certification deadline;
Runtime Admission need;
Publication deadline;
incident severity;
subject criticality;
number of tenants;
number of white-label deployments;
Extension exposure;
dependency centrality;
prior Finding history;
evidence freshness;
resource availability.

Commercial priority SHALL not lower mandatory assessment depth without valid authority.

27.13.7. Assessment Dependency

An Assessment Dependency SHALL preserve:

source assessment;
dependent assessment;
dependency type;
shared subject;
shared Control;
shared evidence;
sequencing;
failure effect;
provenance.

27.13.8. Common-Control Assessment

A Programme MAY assess a common Control once for multiple subjects only where:

the Control implementation is identical for the claimed population;
the Control owner is identified;
tenant and white-label boundaries are preserved;
subject-specific deviations are evaluated;
evidence supports the complete claimed scope;
the Profile permits inheritance;
validity is current;
provenance is complete.

27.13.9. Assessment Reuse

Assessment activities MAY be reused where:

subject state is unchanged;
requirement and Criterion versions are unchanged;
evidence remains fresh;
assessor competence and authority remain valid;
scope is compatible;
no incident or drift invalidates reuse;
reuse is documented;
provenance is complete.

27.13.10. Reuse Limitation

Reuse SHALL not be permitted merely because:

the same product name is used;
the same vendor is used;
the same cloud service is used;
another tenant passed;
another environment passed;
a previous version passed;
a certificate exists for a dependency.

27.13.11. Programme Independence Model

The independence model SHALL identify:

first-party activities;
second-party activities;
third-party activities;
automated activities;
independent review;
assurance activities;
certification decision activities;
conflicts;
safeguards;
provenance.

27.13.12. Programme Competence Model

The competence model SHALL map:

requirement classes;
subject classes;
methods;
jurisdictions;
frameworks;
Modules;
Components;
assessors;
qualifications;
experience;
limitations;
provenance.

27.13.13. Programme Resource Plan

The resource plan MAY include:

assessors;
domain experts;
security testers;
tenant-isolation testers;
evidence custodians;
test environments;
Runtime capacity;
data access;
support resources;
independent reviewers;
certification decision resources.

27.13.14. Assessment Calendar

The calendar SHALL distinguish:

assessment period;
evidence period;
test window;
remediation window;
review period;
certification decision period;
surveillance period;
Publication window.

27.13.15. Programme Risk Register

Risks SHOULD include:

incomplete subject inventory;
incorrect Profile;
stale Baseline;
unavailable evidence;
evidence tampering;
assessor conflict;
competence gap;
test-environment mismatch;
cross-tenant exposure;
sampling bias;
false-positive Findings;
false-negative Findings;
remediation delay;
certification delay;
public-claim error;
archive failure.

27.13.16. Programme Stage Gates

Stage Gates MAY include:

Programme Charter Approval;
Assessment Admission;
Scope Readiness;
Profile Readiness;
Evidence Readiness;
Test Readiness;
Execution Readiness;
Finding Review Readiness;
Outcome Readiness;
Assessment Package Readiness;
Certification Review Readiness;
Programme Closure Readiness.

27.13.17. Gate Authority

Every Gate SHALL identify:

criteria;
evidence;
validator;
decision authority;
possible outcomes;
override policy;
provenance.

HECATE MAY validate Gate criteria but SHALL not exercise judgement authority unless explicitly assigned to objective conditions.

27.13.18. Programme Change Control

A Programme change SHALL identify:

changed Charter element;
affected assessments;
affected Profiles;
affected evidence;
affected tests;
independence impact;
schedule impact;
certification impact;
approval;
provenance.

27.13.19. Programme Scope Change

A material scope change SHALL trigger:

inventory update;
applicability reassessment;
traceability update;
evidence-plan update;
test-plan update;
sampling reassessment;
assessor reassignment where needed;
certification-scope reassessment.

27.13.20. Programme Suspension

Suspension MAY be triggered by:

invalid authority;
invalid Baseline;
invalid Profile;
systemic evidence-integrity concern;
tenant-isolation incident;
assessor-independence failure;
unavailable competence;
compromised test environment;
legal hold on activities;
material subject change.

27.13.21. Programme Closure

Closure SHALL require:

included assessments resolved or transferred;
open Findings assigned;
unresolved exceptions recorded;
certification dependencies transferred;
evidence archived;
access reviewed;
metrics completed;
provenance complete.

27.13.22. Programme Registry

The Programme Registry SHALL preserve:

identities;
Charters;
Portfolios;
dependencies;
risk;
stage Gates;
changes;
suspensions;
closure;
provenance.

27.13.23. Programme Receipt

A receipt SHOULD contain:

Programme;
Charter;
included assessments;
Baselines;
Profiles;
Schemes;
affected tenants;
affected Modules and Components;
risk;
lifecycle;
provenance.

27.13.24. Programme Validation

HECATE SHALL validate:

Programme identity;
Charter;
authority;
Portfolio;
Baselines;
Profiles;
independence;
competence;
Stage Gates;
changes;
closure;
provenance.

27.14. Subject Discovery, Inventory and Scope Resolution

An assessment SHALL be based on an authoritative and sufficiently complete inventory of the subject and its dependencies.

Subject discovery SHALL identify actual deployed and governed state rather than only intended architecture.

27.14.1. Subject Discovery Plan

Every material discovery effort SHALL possess:

Discovery Plan Identifier;
assessment;
target subject classes;
discovery sources;
discovery methods;
environments;
tenants;
white-label deployments;
Modules;
Components;
Extensions;
external dependencies;
period;
owner;
limitations;
provenance.

27.14.2. Discovery Sources

Discovery Sources MAY include:

Constitutional Registries;
Module Registry;
Component Registry;
Extension Registry;
Package Registry;
Runtime Manifest Registry;
tenant Registry;
white-label Registry;
service catalogue;
deployment inventory;
infrastructure inventory;
schema Registry;
API catalogue;
event catalogue;
workflow Registry;
Agent Registry;
tool Registry;
Connector Registry;
Publication Registry;
archive;
source repositories;
configuration systems;
observability systems.

27.14.3. Discovery Methods

Methods MAY include:

Registry query;
Manifest inspection;
deployment inspection;
configuration inspection;
code inspection;
graph traversal;
event-stream analysis;
service discovery;
API discovery;
network inspection;
interview;
walkthrough;
sample verification;
historical reconstruction.

27.14.4. Discovery Object

Every discovered material subject SHALL possess:

Discovery Object Identifier;
discovered identity;
claimed identity;
subject class;
owner;
source;
environment;
tenant or white-label scope;
Module;
Component;
version;
lifecycle;
confidence;
discovery time;
provenance.

27.14.5. Authoritative Inventory

An Authoritative Inventory SHALL distinguish:

constitutionally registered subjects;
deployed subjects;
configured subjects;
active subjects;
inactive subjects;
deprecated subjects;
withdrawn subjects;
historical subjects;
unregistered subjects;
unresolved subjects.

27.14.6. Inventory Classes

Inventory Classes MAY include:

Constitutional Artefact Inventory;
Module Inventory;
Component Inventory;
Capability Inventory;
Runtime Bundle Inventory;
Runtime Manifest Inventory;
Extension Inventory;
Tenant Inventory;
White-Label Inventory;
Data Store Inventory;
Graph Store Inventory;
Event Inventory;
Workflow Inventory;
Agent Inventory;
Model Inventory;
Tool Inventory;
Connector Inventory;
Publication Inventory;
Evidence Store Inventory;
Archive Inventory.

27.14.7. Module Inventory

The Module Inventory SHALL identify:

Module identity;
constitutional responsibility;
owner;
capabilities;
Components;
data ownership;
event ownership;
workflow ownership;
external contracts;
tenants served;
Runtime versions;
provenance.

27.14.8. Component Inventory

The Component Inventory SHALL identify:

Component identity;
owning Module;
capability;
version;
deployment;
contract;
authority;
state;
dependencies;
tenants served;
white-label scopes;
evidence interfaces;
provenance.

27.14.9. Orphan Component

A discovered Component without explicit Module ownership SHALL produce a Finding.

It SHALL not be silently assigned during assessment without governed authority.

27.14.10. Shadow Component

A Shadow Component is deployed or active but absent from the governed Component Registry.

It SHALL be classified, contained where necessary and evaluated for:

authority;
capability;
tenant access;
security;
evidence;
conformance;
registration or retirement.

27.14.11. Hidden Dependency

A Hidden Dependency is materially relied upon but absent from the declared subject boundary.

Examples MAY include:

shared database;
external model;
unmanaged script;
manual spreadsheet;
undocumented API;
shared queue;
shared cache;
external identity provider;
partner service;
unregistered agent tool.

27.14.12. Extension Inventory

The Extension Inventory SHALL include:

global Extensions;
framework Extensions;
jurisdictional Extensions;
white-label Extensions;
tenant Extensions;
organisation Extensions;
partner Extensions;
private Extensions;
deprecated Extensions;
withdrawn Extensions;
historical Extensions.

27.14.13. Tenant Inventory

The tenant inventory SHALL identify:

Tenant Identifier;
operator;
active Baseline;
Runtime Bundle;
Runtime Manifest;
Extension Set;
Modules;
Components;
jurisdictions;
data residency;
integrations;
Publications;
assessment status;
provenance.

27.14.14. White-Label Inventory

The white-label inventory SHALL identify:

operator;
tenant population;
operator Extensions;
shared Modules;
shared Components;
public domains;
branded Publications;
integrations;
support model;
jurisdictions;
provenance.

27.14.15. External Dependency Inventory

Every material external dependency SHALL identify:

provider;
service;
contract;
version;
data exchanged;
authority;
tenant scope;
security;
certification;
evidence;
availability;
fallback;
provenance.

27.14.16. Shared-Service Inventory

A shared service SHALL identify:

tenant context propagation;
partitioning;
access model;
common Controls;
exceptions;
resource isolation;
failure isolation;
observability;
provenance.

27.14.17. Inventory Reconciliation

Inventory reconciliation SHALL compare as applicable:

constitutional Registry;
deployment state;
configuration state;
Runtime Manifest;
observed traffic;
event producers and consumers;
workflow definitions;
Agent tool access;
Publication sources;
archive state.

27.14.18. Inventory Finding

An Inventory Finding SHALL identify:

expected subject;
observed subject;
discrepancy;
source systems;
affected scopes;
severity;
remediation;
provenance.

27.14.19. Scope Resolution Context

Scope resolution SHALL consider:

assessment purpose;
Baseline;
Profile;
Certification Scheme;
jurisdiction;
tenant;
white-label deployment;
Module;
Component;
Extension;
environment;
period;
Publication class;
dependency criticality.

27.14.20. Scope Manifest

Every material assessment SHALL possess a Scope Manifest containing:

Assessment Identifier;
Units of Assessment;
subject Snapshots;
included dependencies;
inherited dependencies;
excluded subjects;
excluded dependencies;
shared Controls;
tenant and white-label boundaries;
Module and Component boundaries;
Extension boundaries;
environments;
periods;
jurisdictions;
limitations;
digest;
provenance.

27.14.21. Inclusion Rule

Every included subject SHALL identify why it is included and which requirements apply.

27.14.22. Exclusion Rule

Every exclusion SHALL identify:

excluded subject;
reason;
authority;
materiality;
dependency effect;
Outcome effect;
claim limitation;
provenance.

Mandatory applicable subjects SHALL not be excluded for convenience.

27.14.23. Boundary Interface

Every material boundary interface SHALL identify:

source subject;
target subject;
contract;
data;
event;
authority;
tenant context;
security;
evidence;
provenance.

27.14.24. Scope Completeness

Scope completeness MAY be:

Complete;
Materially Complete;
Complete with Controlled Exclusions;
Partial;
Reconstructed;
Indeterminate.

Partial or Indeterminate scope SHALL restrict the Outcome and public claim.

27.14.25. Subject Snapshot Assembly

A Subject Snapshot SHALL capture as applicable:

subject identity;
Baseline;
source digests;
Runtime Bundle;
Runtime Manifest;
Extension Set;
Module versions;
Component versions;
schemas;
policies;
workflows;
events;
Agent Profiles;
model versions;
tool contracts;
Connector versions;
configuration;
environment;
tenant routing;
effective time;
provenance.

27.14.26. Snapshot Integrity

Snapshot integrity SHOULD be protected through:

canonical serialization;
content digests;
Manifest;
trusted timestamp;
signatures where required;
immutable storage;
provenance.

27.14.27. Dynamic Subject Snapshot

A dynamic subject MAY use:

initial Snapshot;
observation-window state;
change log;
Runtime Manifest history;
Extension Set history;
configuration history;
drift events;
final Snapshot.

27.14.28. Scope Freeze

Scope Freeze SHALL bind:

Scope Manifest;
Subject Snapshots;
Profile versions;
requirement inventory;
environment;
assessment period;
digest;
provenance.

27.14.29. Scope Change

A post-freeze change SHALL be classified as:

non-material;
material but bounded;
material requiring partial reassessment;
material requiring complete reassessment;
invalidating the assessment.

27.14.30. Scope Change Receipt

A receipt SHOULD contain:

prior Scope Manifest;
changed subject;
reason;
impact;
decision;
updated Plan;
authority;
provenance.

27.14.31. Discovery and Scope Validation

HECATE SHALL validate:

Discovery Plan;
inventory identities;
Module and Component membership;
Extension inventory;
tenant and white-label boundaries;
dependency inventory;
Scope Manifest;
exclusions;
Snapshot integrity;
scope freeze;
provenance.

27.15. Requirement Traceability, Control Mapping and Coverage Analysis

Every assessment SHALL maintain bidirectional traceability from authoritative Requirement Source to Conformance Outcome.

Traceability SHALL permit a reviewer to determine:

why a requirement applies;
how it is controlled;
how it is tested;
which evidence supports the result;
which Findings affect it;
how it influences the Outcome.

27.15.1. Conformance Traceability Matrix

Every material assessment SHALL possess a Conformance Traceability Matrix, abbreviated CTM, containing:

Matrix Identifier;
assessment;
Baseline;
Profile;
requirement inventory;
applicability;
Control Objectives;
Controls;
Criteria;
Test Specifications;
Evidence Requirements;
Evidence Objects;
Test Executions;
Findings;
exceptions;
remediation;
Outcome effect;
version;
digest;
provenance.

27.15.2. Traceability Directions

The CTM SHALL support:

forward traceability from requirement to Outcome;
reverse traceability from Outcome to requirements;
evidence traceability;
Finding traceability;
Control traceability;
test traceability;
change-impact traceability;
historical traceability.

27.15.3. Requirement Coverage

Every applicable requirement SHALL possess a coverage state.

Coverage states MAY include:

Fully Covered;
Covered by Multiple Controls;
Covered by Compensating Control;
Partially Covered;
Indirectly Covered;
Not Covered;
Evidence Pending;
Test Pending;
Unable to Determine;
Not Applicable.

27.15.4. Control Objective Coverage

Coverage SHALL determine whether Controls collectively satisfy the Control Objective.

A collection of Controls SHALL not be assumed complete merely because each addresses part of the objective.

27.15.5. Control-to-Criterion Mapping

Every material Control SHALL map to one or more Criteria capable of assessing:

design;
implementation;
operation;
output;
exception;
monitoring;
failure handling.

27.15.6. Criterion-to-Test Mapping

Every objective Criterion SHOULD map to one or more approved Test Specifications.

A judgement Criterion SHALL map to a governed review method and decision rubric.

27.15.7. Test-to-Evidence Mapping

Every Test Execution SHALL identify the Evidence Objects it consumes and produces.

27.15.8. Finding-to-Requirement Mapping

Every adverse Finding SHALL map to:

requirement;
Criterion;
subject;
affected Control;
evidence;
Outcome effect.

27.15.9. One-to-Many Mapping

One requirement MAY map to multiple Controls and Tests.

The CTM SHALL preserve the logical composition.

27.15.10. Many-to-One Mapping

Multiple requirements MAY map to one Control or Test.

The CTM SHALL preserve each source requirement and applicability.

27.15.11. Control Overlap

Control overlap SHALL identify:

overlapping objectives;
shared evidence;
duplicate testing;
conflicting operation;
common-cause failure;
optimisation opportunity;
provenance.

27.15.12. Common-Control Mapping

A common Control SHALL identify:

provider;
implementation;
subject population;
tenant scope;
white-label scope;
Modules;
Components;
exceptions;
evidence;
inheritance rules;
validity;
provenance.

27.15.13. Shared-Responsibility Mapping

The CTM SHALL distinguish responsibility among:

ZAYAZ Core;
white-label operator;
tenant;
organisation;
Module owner;
Component owner;
Extension publisher;
external provider;
assessor.

27.15.14. Responsibility Gap

A Responsibility Gap exists where no accountable party owns a requirement, Control, evidence obligation or remediation.

It SHALL produce a Finding.

27.15.15. Requirement Conflict

The CTM SHALL identify:

conflicting requirements;
source authorities;
precedence;
affected Controls;
affected Tests;
resolution state;
Outcome effect;
provenance.

27.15.16. Requirement Equivalence Mapping

An external requirement MAY be mapped as:

Equivalent;
Substantially Equivalent;
Narrower;
Broader;
Partially Overlapping;
Conditional;
Incompatible;
Unable to Determine.

Equivalence SHALL not be inferred from similar labels alone.

27.15.17. Framework Crosswalk

A Framework Crosswalk SHALL identify:

source framework;
target framework;
source requirement;
target requirement;
mapping type;
conditions;
gaps;
authority;
version;
provenance.

27.15.18. Coverage Gap

A Coverage Gap SHALL possess:

Gap Identifier;
requirement;
missing Control, Criterion, Test or evidence;
subject;
severity;
interim treatment;
owner;
remediation;
Outcome effect;
provenance.

27.15.19. Redundant Coverage

Redundant coverage MAY be retained for resilience.

The CTM SHOULD identify:

independent redundancy;
correlated redundancy;
duplicate evidence;
unnecessary testing;
common-cause failure.

27.15.20. Coverage Metric

A coverage metric SHALL identify:

covered population;
denominator;
weighting where permitted;
excluded requirements;
mandatory requirements;
critical requirements;
limitations;
provenance.

A high aggregate percentage SHALL not offset failure of a mandatory critical requirement.

27.15.21. Critical Requirement Override

A critical or blocking requirement SHALL override aggregate scoring where the Profile requires.

27.15.22. Traceability Versioning

The CTM SHALL be versioned.

A material change to:

Baseline;
Profile;
applicability;
subject;
Control;
Test;
evidence;
Finding

SHALL create an updated version and impact analysis.

27.15.23. Traceability Freeze

The final CTM used for Outcome determination SHALL be frozen and integrity-protected.

27.15.24. Traceability Drift

Traceability Drift exists where actual assessment execution differs from the frozen CTM.

Examples include:

unplanned Test;
missing Test;
changed Criterion;
replaced evidence;
changed subject;
unmapped Finding;
changed Control owner.

27.15.25. Traceability Reconciliation

Reconciliation SHALL confirm:

all applicable requirements treated;
all Controls mapped;
all Criteria mapped;
all Test Executions accounted for;
all evidence linked;
all Findings linked;
all exceptions linked;
Outcome derivation complete.

27.15.26. Traceability Graph

The CCCF SHOULD expose a graph capable of traversing:

Requirement Source
        │
        ▼
Requirement
        │
        ▼
Control Objective
        │
        ▼
Control
        │
        ▼
Criterion
        │
        ▼
Test Specification
        │
        ▼
Test Execution
        │
        ▼
Evidence Object
        │
        ▼
Finding
        │
        ▼
Remediation or Exception
        │
        ▼
Conformance Outcome

27.15.27. Module and Component Traceability

Every material Requirement and Control SHALL identify as applicable:

accountable Module;
implementing Component;
supporting Components;
shared-service Components;
tenant scope;
contract version;
evidence source;
provenance.

27.15.28. Change Impact

A changed Requirement, Control, Criterion or Test SHALL identify impacted:

active assessments;
Evidence Plans;
Test Suites;
Findings;
Outcomes;
Certificates;
Runtime Admissions;
Publications;
tenants;
white-label deployments;
Modules;
Components;
Extensions.

27.15.29. CTM Receipt

A receipt SHOULD contain:

Matrix Identifier;
Baseline;
Profile;
requirement count;
coverage state;
critical gaps;
traceability drift;
reconciliation;
digest;
provenance.

27.15.30. Traceability Validation

HECATE SHALL validate:

CTM identity;
requirement source;
applicability;
mappings;
coverage;
responsibility;
conflicts;
gaps;
critical overrides;
freeze;
reconciliation;
provenance.

27.16. Evidence Architecture, Acquisition and Chain of Custody

Evidence architecture SHALL ensure that evidence used in conformance assessment is authentic, relevant, sufficient, minimally invasive, tenant-safe and reproducible.

Evidence collection SHALL not create uncontrolled operational, privacy, security or Publication effects.

27.16.1. Evidence Plan

Every formal assessment SHALL possess an Evidence Plan containing:

Evidence Plan Identifier;
assessment;
subject;
Scope Manifest;
Baseline;
Profile;
Evidence Requirements;
requested Evidence Classes;
source systems;
acquisition methods;
sampling;
freshness;
integrity controls;
classification;
tenant and white-label controls;
minimisation;
retention;
access;
owners;
schedule;
limitations;
provenance.

27.16.2. Evidence Acquisition Classes

Acquisition Classes MAY include:

direct system extraction;
governed API extraction;
signed export;
immutable log query;
event replay;
Runtime Manifest capture;
source-code capture;
configuration capture;
database query;
graph query;
file capture;
screenshot or visual record;
interview;
observation;
confirmation;
external provider submission;
tenant submission;
assurance-provider submission;
regulator submission.

27.16.3. Direct Evidence

Direct evidence is produced by or captured from the assessed subject or authoritative source.

27.16.4. Indirect Evidence

Indirect evidence supports an inference about the subject.

The inference, limitations and corroboration SHALL be explicit.

27.16.5. Evidence Request Object

Every material Evidence Request SHALL possess:

Request Identifier;
assessment;
requirement or Criterion;
requested subject;
Evidence Class;
period;
format;
source;
authority;
due time;
classification;
tenant scope;
minimisation;
provenance.

27.16.6. Evidence Collection Authority

Collection SHALL identify:

collector;
authority;
purpose;
permitted systems;
permitted tenants;
read or write capability;
time;
supervision;
provenance.

27.16.7. Non-Destructive Collection

Evidence collection SHOULD be read-only.

Where write or execution effects are necessary, the Plan SHALL define:

authority;
side effects;
containment;
rollback;
tenant protection;
monitoring;
incident response;
provenance.

27.16.8. Evidence Minimisation

Collection SHALL be limited to evidence necessary for the defined assessment.

Minimisation SHALL consider:

personal data;
tenant-confidential data;
trade secrets;
privileged material;
security-sensitive data;
unrelated records;
retention burden.

27.16.9. Evidence Segregation

Evidence SHALL be segregated by:

tenant;
white-label operator;
assessment;
subject;
classification;
jurisdiction;
retention;
access authority.

27.16.10. Multi-Tenant Evidence

Multi-tenant evidence MAY be used only where:

the Control is genuinely common;
tenant context remains observable;
sensitive tenant details are protected;
exceptions remain detectable;
the assessment scope permits aggregation;
provenance remains complete.

27.16.11. Evidence Redaction

Redaction SHALL preserve:

source Evidence Object;
redacted fields;
reason;
authority;
method;
impact on assessment;
unredacted controlled-access location;
source and redacted digests;
provenance.

27.16.12. Pseudonymisation

Pseudonymisation SHALL preserve:

method;
key or mapping governance;
reidentification authority;
tenant separation;
assessment utility;
retention;
provenance.

27.16.13. Evidence Capture Manifest

Every material capture SHOULD possess a Manifest identifying:

Evidence Objects;
source systems;
queries or extraction methods;
collectors;
times;
digests;
signatures;
classifications;
tenant scopes;
transformations;
provenance.

27.16.14. Evidence Package

An Evidence Package is an integrity-protected collection of Evidence Objects for a defined assessment scope.

Every Evidence Package SHALL possess:

Package Identifier;
assessment;
subject;
Snapshot;
Evidence Object inventory;
Manifest;
content digests;
classifications;
access policy;
retention;
lifecycle;
version;
provenance.

27.16.15. Evidence Package Types

Types MAY include:

Design Evidence Package;
Implementation Evidence Package;
Operating-Effectiveness Evidence Package;
Security Evidence Package;
Tenant-Isolation Evidence Package;
Runtime Evidence Package;
Extension Evidence Package;
Publication Evidence Package;
Historical Evidence Package;
Remediation Evidence Package;
Certification Evidence Package.

27.16.16. Evidence Package Immutability

A submitted Evidence Package SHALL be immutable.

Additional or corrected evidence SHALL create a new Package version or Supplemental Package.

27.16.17. Evidence Signature

A signature MAY bind:

Package Identifier;
Manifest digest;
Evidence Object digests;
submitter;
authority;
submission time;
key;
provenance.

27.16.18. Evidence Chain of Custody

The chain of custody SHALL preserve:

origin;
collector;
acquisition method;
extraction query or procedure;
transfer;
transformation;
storage;
access;
review;
export;
archive;
destruction;
provenance.

27.16.19. Evidence Transformation

Every transformation SHALL identify:

source Evidence Object;
target Evidence Object;
transformation method;
actor or Component;
source digest;
target digest;
information loss;
semantic effect;
authority;
time;
provenance.

27.16.20. Evidence Normalisation

Normalisation MAY support comparison.

It SHALL preserve:

original values;
original units;
original time;
original identity;
normalisation method;
precision;
uncertainty;
provenance.

27.16.21. Evidence Aggregation

Aggregation SHALL preserve:

source population;
aggregation method;
missing-data treatment;
tenant treatment;
period;
information loss;
ability to inspect source evidence where authorised;
provenance.

27.16.22. Evidence Quality Assessment

Evidence quality MAY be evaluated across:

authority;
authenticity;
relevance;
sufficiency;
completeness;
freshness;
integrity;
independence;
reproducibility;
granularity;
tenant specificity;
uncertainty.

A quality score SHALL remain analytical and SHALL not replace judgement about sufficiency.

27.16.23. Evidence Freshness Window

Every Evidence Requirement SHOULD define:

maximum age;
observation period;
refresh trigger;
incident trigger;
change trigger;
expiration effect;
provenance.

27.16.24. Evidence Expiration

Expired evidence SHALL be:

refreshed;
supplemented;
accepted with explicit limitation where permitted;
rejected;
used only for historical assessment.

It SHALL not remain current silently.

27.16.25. Evidence Revocation

Evidence MAY be revoked or invalidated due to:

falsification;
source compromise;
signature compromise;
incorrect extraction;
wrong tenant scope;
incomplete population;
superseded source;
legal restriction.

Revocation SHALL identify affected Tests, Findings, Outcomes and Certificates.

27.16.26. Evidence Conflict

Evidence conflict SHALL trigger:

source comparison;
authority comparison;
period comparison;
subject comparison;
extraction review;
additional evidence;
unresolved-state classification;
Outcome limitation;
provenance.

27.16.27. Evidence Gap Treatment

A material gap MAY result in:

additional request;
alternative evidence;
expanded sampling;
additional Test;
Indeterminate Finding;
scope limitation;
assessment suspension;
non-conformity where evidence itself is mandatory.

27.16.28. External Evidence

External evidence SHALL identify:

provider;
authority;
subject;
scope;
method;
version;
validity;
independence;
limitations;
verification;
provenance.

27.16.29. External Certificate as Evidence

An external Certificate SHALL preserve:

Scheme;
subject;
scope;
validity;
certification body;
accreditation state where claimed;
criteria mapping;
limitations;
verification;
provenance.

27.16.30. Agent and Model Evidence

Evidence concerning an agent or model SHALL preserve as applicable:

Agent Profile;
model identity;
model version;
provider;
instructions;
prompts;
retrieval sources;
tools;
parameters;
tenant context;
inputs;
outputs;
evaluations;
limitations;
provenance.

27.16.31. Privileged Evidence

Legally privileged or similarly protected evidence SHALL preserve:

privilege classification;
holder;
access;
permitted use;
disclosure restriction;
redaction;
retention;
provenance.

27.16.32. Evidence Access Log

Access logging SHALL identify:

actor;
Role;
Evidence Object or Package;
purpose;
action;
time;
tenant scope;
export;
provenance.

27.16.33. Evidence Retention

Retention SHALL align with:

assessment;
Outcome validity;
Certification Scheme;
legal requirements;
tenant contracts;
appeal periods;
audit needs;
Legal Holds;
historical verification.

27.16.34. Evidence Destruction

Destruction SHALL require:

retention expiry;
no Legal Hold;
no active appeal;
no active certification dependency;
no unresolved Finding dependency;
authority;
verified destruction;
minimal Destruction Record.

27.16.35. Evidence Receipt

An Evidence Receipt SHOULD contain:

assessment;
Package;
Manifest digest;
Evidence Object inventory;
source classes;
tenant scopes;
integrity;
freshness;
access classification;
submitter;
time;
provenance.

27.16.36. Evidence Validation

HECATE SHALL validate:

Evidence Plan;
Request;
collection authority;
tenant scope;
minimisation;
Package;
Manifest;
integrity;
chain of custody;
transformations;
freshness;
revocation;
retention;
provenance.

27.17. Test Engineering and Conformance Fixture Design

A conformance test SHALL be designed to evaluate one or more governed Criteria against an exact subject, Snapshot, Baseline and environment.

Test engineering SHALL preserve the distinction between:

Criterion;
Test Specification;
Test Fixture;
Test Oracle;
Test Execution;
Test Result;
Finding;
Conformance Outcome.

27.17.1. Conformance Test Suite

Every material assessment SHOULD possess a Conformance Test Suite containing:

Suite Identifier;
assessment;
Baseline;
Profile;
subject classes;
Test Specifications;
Test Fixtures;
Test Oracles;
environment requirements;
sequencing;
dependencies;
coverage;
version;
lifecycle;
digest;
provenance.

27.17.2. Test Suite Types

Types MAY include:

Core Semantic Test Suite;
Schema Conformance Test Suite;
Registry Conformance Test Suite;
Graph Conformance Test Suite;
Policy Conformance Test Suite;
Decision Conformance Test Suite;
Computation Conformance Test Suite;
Methodology Conformance Test Suite;
Workflow Conformance Test Suite;
Event and Command Conformance Test Suite;
Agent Conformance Test Suite;
Model Conformance Test Suite;
Tool Conformance Test Suite;
Module Conformance Test Suite;
Component Conformance Test Suite;
Extension Conformance Test Suite;
Tenant-Isolation Test Suite;
Security Test Suite;
Runtime Conformance Test Suite;
Publication Conformance Test Suite;
Historical-Replay Test Suite.

27.17.3. Test Specification Identity

Every Test Specification SHALL possess:

Test Identifier;
canonical name;
Criterion;
requirement;
subject classes;
method;
inputs;
preconditions;
environment;
expected result;
tolerance;
oracle;
fixture requirements;
side-effect policy;
repeatability;
severity on failure;
version;
lifecycle;
provenance.

27.17.4. Test Fixture

A Test Fixture is the controlled data, state, configuration or environment required for a Test Execution.

Every material Fixture SHALL possess:

Fixture Identifier;
Test Specification;
subject class;
Baseline;
input data;
initial state;
tenant context;
white-label context;
Extension context;
expected relationships;
sensitivity classification;
lifecycle;
version;
digest;
provenance.

27.17.5. Fixture Classes

Fixture Classes MAY include:

Positive Fixture;
Negative Fixture;
Boundary Fixture;
Invalid-State Fixture;
Historical Fixture;
Migration Fixture;
Multi-Tenant Fixture;
White-Label Fixture;
Extension Fixture;
Security Fixture;
Publication Fixture;
Replay Fixture;
Failure-Injection Fixture;
Recovery Fixture.

27.17.6. Test Oracle

A Test Oracle defines the governed basis for determining the expected result.

Every Oracle SHALL identify:

Oracle Identifier;
Criterion;
authoritative source;
expected semantics;
decision rule;
tolerance;
ambiguity treatment;
version;
provenance.

27.17.7. Oracle Authority

A Test Oracle SHALL derive from:

authoritative constitutional meaning;
approved Profile;
approved methodology;
approved reference data;
approved deterministic rule;
authorised expert judgement rubric.

Historical system output SHALL not become the Oracle merely because it exists.

27.17.8. Golden Vector

A Golden Vector SHALL preserve:

input;
context;
expected output;
expected explanation;
expected authority;
expected evidence;
tolerance;
Baseline;
source;
provenance.

27.17.9. Positive Test

A Positive Test SHALL demonstrate that valid state is accepted or produces the required outcome.

27.17.10. Negative Test

A Negative Test SHALL demonstrate that prohibited or invalid state is rejected, blocked, quarantined, escalated or otherwise treated according to the Criterion.

27.17.11. Boundary Test

A Boundary Test SHALL evaluate:

minimum;
maximum;
threshold;
transition;
exact-equality;
immediately-before;
immediately-after;
null or absence semantics;
temporal boundary.

27.17.12. Property-Based Test

Property-based testing MAY validate invariant properties across generated inputs.

It SHALL preserve:

property;
generator;
constraints;
seed;
shrinking method;
failing case;
provenance.

27.17.13. Metamorphic Test

A Metamorphic Test MAY validate expected relationships among outputs when controlled input transformations are applied.

The metamorphic relation SHALL derive from governed meaning.

27.17.14. Differential Test

A Differential Test compares two or more implementations, Baselines, versions, Components or configurations.

The expected equivalence or expected difference SHALL be explicit.

Agreement among implementations SHALL not establish correctness without an Oracle.

27.17.15. Mutation Test

Mutation testing MAY evaluate whether a Test Suite detects intentionally introduced defects.

Mutation results MAY support Test Suite quality but SHALL not establish subject conformance directly.

27.17.16. Replay Test

A Replay Test SHALL identify:

historical or captured input;
Baseline;
Runtime Bundle;
Runtime Manifest;
Extension Set;
Modules;
Components;
time;
replay mode;
isolation;
expected result;
limitations;
provenance.

27.17.17. Schema Test

Schema testing MAY evaluate:

required properties;
datatypes;
cardinality;
constraints;
namespaces;
units;
null semantics;
compatibility;
historical versions.

27.17.18. Registry Test

Registry testing MAY evaluate:

identity uniqueness;
code validity;
lifecycle;
hierarchy;
aliases;
mappings;
version;
effective time;
authority;
tenant Extensions.

27.17.19. Graph Test

Graph testing MAY evaluate:

node identity;
Relationship Types;
endpoint constraints;
cardinality;
cycles;
paths;
temporal overlap;
tenant boundaries;
inference;
provenance.

27.17.20. Policy Test

Policy testing SHALL identify:

Policy identity;
input context;
subject;
resource;
action;
expected effect;
combining algorithm;
explanation;
override;
provenance.

27.17.21. Decision Test

Decision testing SHALL identify:

Decision Logic;
criteria;
thresholds;
weights;
uncertainty;
expected Outcome;
explanation;
edge cases;
provenance.

27.17.22. Computation Test

Computation testing SHALL identify:

computation identity;
formula or algorithm;
inputs;
units;
factors;
boundaries;
assumptions;
precision;
rounding;
uncertainty;
expected result;
tolerance;
provenance.

27.17.23. Methodology Test

Methodology testing MAY evaluate:

scope;
boundary;
exclusions;
factors;
allocation;
time period;
uncertainty;
comparability;
assurance requirements;
Publication consequences.

27.17.24. Workflow Test

Workflow testing SHALL identify:

Workflow identity;
initial state;
Tasks;
Gates;
Roles;
transitions;
timers;
retries;
compensation;
expected completion;
side effects;
provenance.

27.17.25. Event and Command Test

Testing SHALL preserve:

Event or Command Type;
schema;
semantics;
producer or issuer;
consumer or target;
authority;
ordering;
idempotency;
correlation;
causation;
replay;
side effects.

27.17.26. Agent Test

Agent testing SHALL evaluate as applicable:

Agent Profile;
purpose;
instructions;
model;
retrieval;
tools;
authority;
autonomy;
escalation;
tenant isolation;
refusal;
evidence use;
output;
side effects;
reproducibility limitations.

27.17.27. Model Test

Model testing MAY evaluate:

model identity;
version;
provider;
input handling;
output quality;
bias;
robustness;
privacy;
security;
drift;
explainability;
uncertainty;
fallback.

27.17.28. Tool Test

Tool testing SHALL evaluate:

Tool identity;
input schema;
output schema;
authority;
side effects;
idempotency;
failure;
timeout;
rollback or compensation;
tenant scope;
provenance.

27.17.29. Module Test

A Module Test SHALL evaluate:

constitutional responsibility;
capability completeness;
Component membership;
data ownership;
event ownership;
policy ownership;
workflow ownership;
external contracts;
security;
reliability;
evidence;
provenance.

27.17.30. Component Test

A Component Test SHALL evaluate:

owning Module;
capability;
contract;
configuration;
authority;
state;
dependencies;
security;
tenant isolation;
reliability;
observability;
provenance.

27.17.31. Extension Test

An Extension Test SHALL evaluate:

Extension Point;
Namespace;
Package;
Manifest;
dependency lock;
Core Baseline;
precedence;
tenant scope;
security;
Runtime behaviour;
Publication impact;
provenance.

27.17.32. Tenant-Isolation Test

Tenant-isolation testing SHALL cover as applicable:

relational data;
object storage;
graph;
cache;
search;
vector stores;
event streams;
workflows;
agents;
tools;
models;
logs;
backups;
archives;
Publications.

27.17.33. Publication Test

Publication testing SHALL evaluate:

source Baseline;
source Outcome;
values;
units;
methodology;
boundaries;
audience;
disclosure;
assurance;
format;
signatures;
correction state;
verification.

27.17.34. Test Data Governance

Test data SHALL be:

authorised;
purpose-bound;
tenant-safe;
classified;
minimised;
versioned;
reproducible;
retained or destroyed according to policy.

27.17.35. Synthetic Test Data

Synthetic data MAY be used where:

generation method is documented;
required distributions and edge cases are represented;
no real personal or tenant-confidential data is reconstructed improperly;
limitations are explicit;
provenance is preserved.

27.17.36. Production-Derived Test Data

Production-derived data SHALL require:

authority;
minimisation;
tenant isolation;
masking or pseudonymisation where required;
access controls;
retention;
destruction;
provenance.

27.17.37. Test Environment Profile

Every material test environment SHALL identify:

environment identity;
Baseline;
Runtime Bundle;
Runtime Manifest;
Extension Set;
Modules;
Components;
configuration;
tenant context;
network context;
external dependencies;
data class;
isolation;
time;
provenance.

27.17.38. Environment Equivalence

A non-production environment SHALL not be assumed equivalent to production.

Equivalence SHALL evaluate:

versions;
configuration;
data shape;
scale;
security;
integrations;
tenant routing;
operational Controls;
observability.

27.17.39. Test Side-Effect Control

Tests SHALL identify whether they may:

mutate data;
mutate graph;
emit events;
transition workflows;
invoke agents;
invoke tools;
contact external systems;
create Publications;
send notifications.

Uncontrolled side effects SHALL be prohibited.

27.17.40. Test Isolation

Isolation MAY use:

dedicated environment;
tenant sandbox;
transaction rollback;
event sink;
mock Connector;
shadow mode;
read-only mode;
feature isolation;
replay isolation.

27.17.41. Test Sequencing

Test sequencing SHALL identify:

prerequisites;
shared state;
destructive order;
reset;
dependency;
parallelisation;
failure handling;
provenance.

27.17.42. Test Repeatability

Repeatability SHALL classify a Test as:

deterministic;
deterministic within tolerance;
statistically repeatable;
conditionally repeatable;
non-deterministic but evaluable;
not repeatable.

27.17.43. Non-Deterministic Test

A non-deterministic Test SHALL define:

distribution or expected range;
sample size;
confidence;
seed where possible;
model or dependency variability;
retry policy;
failure rule;
limitations.

27.17.44. Test Flakiness

A flaky Test SHALL be identified and SHALL not silently determine a blocking Finding without governed treatment.

Flakiness treatment MAY include:

quarantine;
investigation;
repeated execution;
environment correction;
Test correction;
alternative evidence.

27.17.45. False Positive and False Negative Analysis

Critical Tests SHOULD evaluate:

false-positive risk;
false-negative risk;
threshold;
impact;
compensating review;
monitoring;
provenance.

27.17.46. Test Coverage

Coverage SHALL consider:

requirement coverage;
Criterion coverage;
subject coverage;
tenant coverage;
Extension coverage;
Module coverage;
Component coverage;
positive coverage;
negative coverage;
boundary coverage;
historical coverage.

27.17.47. Test Approval

A Test Specification SHALL be approved according to its severity and purpose.

A Test author SHOULD NOT be the sole approver of a certification-blocking Test.

27.17.48. Test Versioning

Test versions SHALL be immutable after approval.

Changes SHALL identify:

reason;
affected Criteria;
changed Oracle;
changed Fixture;
expected result impact;
affected assessments;
affected Outcomes;
provenance.

27.17.49. Test Deprecation

A deprecated Test SHALL identify:

replacement;
effective time;
affected Profiles;
affected assessments;
historical validity;
provenance.

27.17.50. Test Execution Receipt

A receipt SHOULD contain:

Test Specification;
version;
subject Snapshot;
Fixture;
Oracle;
environment;
executor;
Component;
result;
logs;
evidence;
time;
provenance.

27.17.51. Test Engineering Validation

HECATE SHALL validate:

Test Suite;
Test Specification;
Fixture;
Oracle;
source authority;
environment;
data governance;
side-effect controls;
repeatability;
coverage;
version;
provenance.

27.18. Automated Validation, HECATE and Continuous Conformance

Automated validation SHALL evaluate objective Criteria using governed artefacts, controlled environments and reproducible evidence.

Continuous conformance SHALL monitor whether a subject remains within the assessed and certified state after the point-in-time assessment.

27.18.1. Automated Assessment Pipeline

A governed automated pipeline MAY include:

Subject Snapshot Resolution
        │
        ▼
Baseline and Profile Resolution
        │
        ▼
Applicability Resolution
        │
        ▼
Test Suite Resolution
        │
        ▼
Environment and Fixture Validation
        │
        ▼
Test Execution
        │
        ▼
Evidence Capture
        │
        ▼
Objective Finding Derivation
        │
        ▼
Human Escalation where Required
        │
        ▼
Assessment Package Update

27.18.2. Automated Assessment Plan

Every material automated assessment SHALL identify:

Plan Identifier;
subject;
Snapshot;
Baseline;
Profile;
objective Criteria;
Test Suites;
executing Components;
environment;
schedule or trigger;
evidence capture;
failure handling;
escalation;
provenance.

27.18.3. HECATE Validation Plan

A HECATE Validation Plan SHALL identify:

validation targets;
rules;
schemas;
graph shapes;
policies;
Test Specifications;
severity;
blocking conditions;
evidence outputs;
override policy;
version;
provenance.

27.18.4. Objective-Criterion Boundary

Automation MAY determine an objective Criterion only where:

inputs are sufficiently defined;
method is approved;
Oracle is governed;
tolerance is defined;
uncertainty is treated;
result is reproducible or statistically governed.

27.18.5. Judgement Escalation

Where judgement is required, automation SHALL produce:

evidence;
preliminary result;
uncertainty;
explanation;
escalation target;
provenance.

It SHALL not manufacture a final judgement.

27.18.6. Automated Finding

An Automated Finding SHALL identify:

generating Test Execution;
rule;
subject;
evidence;
severity;
confidence;
deterministic or probabilistic basis;
required review;
provenance.

27.18.7. Automated Finding Finality

A Profile MAY permit an objective Automated Finding to become final without human review only where:

rule authority is valid;
criterion is objective;
result is reproducible;
impact is within approved automation scope;
appeal or challenge remains available;
provenance is complete.

27.18.8. Automated Gate

An Automated Gate SHALL identify:

gate subject;
criteria;
blocking rules;
evidence;
outcome;
authority;
override;
expiration;
provenance.

27.18.9. Continuous Conformance Profile

Every continuous-conformance process SHALL possess:

Continuous Profile Identifier;
subject classes;
monitored requirements;
Controls;
indicators;
collection methods;
frequency;
thresholds;
drift rules;
escalation;
validity;
provenance.

27.18.10. Continuous Evidence

Continuous evidence MAY include:

Runtime Manifest state;
deployment state;
configuration state;
policy state;
schema state;
event state;
control telemetry;
security telemetry;
tenant-isolation telemetry;
Extension Set state;
Certificate status;
incident state.

27.18.11. Continuous-Control Monitoring

Monitoring SHALL identify:

Control;
owner;
implementing Component;
observation;
expected state;
frequency;
threshold;
alert;
Finding rule;
provenance.

27.18.12. Event-Triggered Assessment

Events MAY trigger assessment activity including:

BaselineChanged;
RuntimeBundleChanged;
RuntimeManifestChanged;
ComponentChanged;
ModuleOwnershipChanged;
ExtensionSetChanged;
PolicyChanged;
ModelChanged;
ToolPermissionChanged;
TenantScopeChanged;
SecurityIncidentRecorded;
PublicationCorrected;
EvidenceExpired;
CertificateSuspended.

27.18.13. Change-Triggered Reassessment

A material change SHALL be assessed for:

impacted requirements;
impacted Controls;
impacted Tests;
impacted evidence;
impacted Outcomes;
impacted Certificates;
impacted tenants;
impacted Modules and Components;
impacted Publications.

27.18.14. Drift Classes

Drift MAY include:

Constitutional Baseline Drift;
Profile Drift;
Subject Drift;
Configuration Drift;
Runtime Bundle Drift;
Runtime Manifest Drift;
Extension Drift;
Module Drift;
Component Drift;
Control Drift;
Evidence Drift;
Model Drift;
Agent Drift;
Tool Drift;
Publication Drift;
Certification-Claim Drift.

27.18.15. Drift Finding

A Drift Finding SHALL identify:

assessed Snapshot;
current state;
changed element;
affected requirements;
affected scope;
severity;
required action;
validity effect;
provenance.

27.18.16. Drift Tolerance

A tolerance SHALL define:

permitted change;
duration;
affected scope;
approval;
monitoring;
reassessment trigger;
provenance.

27.18.17. Continuous Outcome

A Continuous Conformance Outcome MAY be:

Current;
Current with Conditions;
Degraded;
Reassessment Required;
Suspended;
Non-Conformant;
Indeterminate.

It SHALL remain distinct from the original point-in-time Outcome.

27.18.18. CI/CD Integration

A build or deployment pipeline MAY enforce:

schema validation;
policy validation;
Test Suite execution;
security Controls;
Module and Component manifests;
Extension compatibility;
Runtime Manifest generation;
evidence capture;
Release Gates.

Pipeline success SHALL not by itself establish certification.

27.18.19. Supply-Chain Evidence

Automated assessment MAY consume:

source commit;
dependency lock;
build provenance;
artefact digest;
software bill of materials;
signature;
vulnerability state;
deployment attestation.

The exact authority and scope SHALL remain explicit.

27.18.20. Runtime Admission Gate

A Runtime Admission Gate MAY require:

valid Baseline;
valid Runtime Bundle;
successful critical Tests;
current security evidence;
current tenant-isolation evidence;
valid Module and Component manifests;
compatible Extension Set;
no blocking Finding;
valid authority;
provenance.

27.18.21. Publication Gate

A Publication Gate MAY require:

valid source Outcome;
Publication Profile;
assurance status;
disclosure eligibility;
no blocking Publication Finding;
correction state;
approval;
provenance.

27.18.22. Automated Evidence Extraction

Extraction SHALL preserve:

query or rule;
source system;
source time;
subject;
tenant;
extraction Component;
output digest;
transformation;
provenance.

27.18.23. Automation Failure

Failure classes MAY include:

rule failure;
environment failure;
dependency failure;
timeout;
evidence-capture failure;
tenant-context failure;
signature failure;
result ambiguity;
capacity failure.

Automation failure SHALL not be treated as subject conformance.

27.18.24. Retry Policy

Retry SHALL define:

eligible failures;
maximum attempts;
backoff;
idempotency;
state reset;
evidence preservation;
final failure treatment;
provenance.

27.18.25. Automated Override

An override SHALL identify:

blocked rule;
reason;
authority;
scope;
compensating Control;
expiration;
monitoring;
Outcome effect;
provenance.

27.18.26. AI-Assisted Assessment

AI MAY assist with:

requirement extraction;
mapping suggestions;
evidence triage;
anomaly detection;
test-generation suggestions;
log analysis;
duplicate Finding detection;
root-cause hypotheses;
draft explanations.

27.18.27. AI Assessment Boundary

AI SHALL NOT:

invent source requirements;
create missing evidence;
classify unresolved applicability authoritatively;
accept an exception;
suppress a Finding;
claim independence;
determine certification;
alter evidence;
conceal uncertainty.

27.18.28. Model-Based Validation

Where a model performs classification or evaluation, the Plan SHALL identify:

model;
version;
provider;
training or evaluation basis where available;
prompt or instructions;
input;
output;
confidence;
threshold;
human review;
drift;
provenance.

27.18.29. Non-Deterministic Automation

Non-deterministic automation SHALL define:

repeat strategy;
confidence;
aggregation;
disagreement treatment;
escalation;
reproducibility limitations;
provenance.

27.18.30. Automation Tenant Isolation

Automation SHALL preserve tenant context through:

job scheduling;
data access;
evidence storage;
logs;
model context;
vector retrieval;
cache;
result routing;
Finding routing.

27.18.31. Automation Observability

Observability SHALL preserve:

run identity;
input;
rule and version;
environment;
executor;
duration;
resource use;
errors;
outputs;
evidence;
tenant;
provenance.

27.18.32. Automation Trust Boundary

The architecture SHALL identify:

trusted validators;
untrusted subject inputs;
external services;
model providers;
credential boundaries;
tenant boundaries;
evidence boundaries;
signing boundaries.

27.18.33. Continuous-Conformance Incident

A continuous-control failure MAY trigger:

Finding;
alert;
Runtime hold;
assessment reopening;
Certificate surveillance;
suspension;
Publication correction;
incident response.

27.18.34. Automated Validation Receipt

A receipt SHOULD contain:

Plan;
subject Snapshot;
Baseline;
Profile;
rules;
Test Executions;
evidence;
Findings;
drift;
Gate outcomes;
time;
provenance.

27.18.35. Automated Validation Conformance

HECATE SHALL validate:

Automated Assessment Plan;
rule authority;
objective-Criterion boundary;
Test versions;
environment;
tenant isolation;
evidence extraction;
failure treatment;
override;
drift;
provenance.

27.19. Manual Assessment, Inspection and Expert Judgement

Manual assessment SHALL be used where conformance depends on context, professional competence, observation, interpretation, proportionality or evidence not reducible to deterministic validation.

Human judgement SHALL be structured, evidence-backed, reviewable and challengeable.

27.19.1. Manual Assessment Plan

Every material manual assessment SHALL identify:

Manual Assessment Plan Identifier;
assessment;
subject;
Criteria;
methods;
required competence;
assigned assessors;
independence;
evidence;
decision rubrics;
documentation;
review;
limitations;
provenance.

27.19.2. Manual Assessment Methods

Methods MAY include:

document inspection;
code inspection;
configuration inspection;
design review;
walkthrough;
interview;
observation;
reperformance;
recalculation;
inquiry;
confirmation;
legal analysis;
methodology review;
public-claim review;
historical reconstruction.

27.19.3. Inspection Object

Every material Inspection SHALL possess:

Inspection Identifier;
subject;
Criterion;
inspected artefact or process;
method;
inspector;
time;
evidence;
observations;
result;
limitations;
provenance.

27.19.4. Walkthrough

A walkthrough SHALL preserve:

process;
participants;
roles;
inputs;
steps;
Controls;
evidence;
deviations;
questions;
conclusion;
provenance.

27.19.5. Interview

An interview record SHALL identify:

interviewee;
Role;
subject;
questions;
responses;
corroborating evidence;
confidentiality;
limitations;
assessor;
time;
provenance.

Testimonial evidence SHALL not override stronger contradictory evidence without reasoned resolution.

27.19.6. Observation

Observation SHALL identify:

process;
environment;
period;
participants;
expected behaviour;
observed behaviour;
assessor;
limitations;
provenance.

27.19.7. Reperformance

Reperformance SHALL preserve:

original process or calculation;
inputs;
method;
assessor;
expected result;
reproduced result;
divergence;
provenance.

27.19.8. Manual Recalculation

Recalculation SHALL preserve:

formula;
variables;
units;
factors;
assumptions;
precision;
original result;
recalculated result;
variance;
provenance.

27.19.9. Expert Judgement Criterion

Every expert judgement SHALL identify:

Criterion;
question;
required expertise;
evidence considered;
framework or rubric;
alternatives;
uncertainty;
conclusion;
rationale;
assessor;
review;
provenance.

27.19.10. Judgement Rubric

A rubric SHOULD define:

evaluation dimensions;
rating levels;
minimum evidence;
materiality;
unacceptable states;
escalation;
limitations;
provenance.

27.19.11. Professional Scepticism

Assessors SHOULD:

question contradictory evidence;
investigate unusual consistency;
distinguish assertion from evidence;
consider management or operator bias;
seek corroboration;
document uncertainty.

27.19.12. Assessor Competence

Competence SHALL be evaluated for:

constitutional framework;
subject domain;
applicable law or regulation;
methodology;
security;
tenant isolation;
Runtime architecture;
Module and Component architecture;
Extension architecture;
Publication;
assurance or certification method.

27.19.13. Competence Evidence

Evidence MAY include:

qualification;
licence;
certification;
experience;
training;
supervised work;
peer review;
performance evaluation;
domain publications.

27.19.14. Competence Limitation

A limitation SHALL identify:

assessor;
affected Criteria;
missing competence;
compensating expertise;
review;
Outcome effect;
provenance.

27.19.15. Assessor Independence

Independence SHALL evaluate:

authorship;
implementation involvement;
financial interest;
management responsibility;
Module ownership;
Component ownership;
tenant relationship;
white-label relationship;
consulting relationship;
prior decision involvement.

27.19.16. Familiarity Threat

Long-term familiarity with a subject or assessed party MAY create a threat requiring:

rotation;
independent review;
peer challenge;
increased evidence;
disclosure.

27.19.17. Self-Review Threat

An assessor SHALL not provide sole independent judgement over work they designed or implemented where independence is required.

27.19.18. Advocacy Threat

An actor who promotes a subject, certification claim or commercial outcome SHALL not be treated as independent without appropriate safeguards.

27.19.19. Assessor Bias Controls

Controls MAY include:

blind review;
structured rubric;
independent second review;
calibration;
evidence sequencing;
dissent recording;
conflict disclosure;
rotation.

27.19.20. Calibration

Assessor calibration MAY use:

common cases;
Golden Vectors;
example Findings;
severity comparison;
materiality exercises;
disagreement review;
periodic retraining.

27.19.21. Inter-Rater Agreement

Agreement metrics MAY support quality monitoring.

They SHALL not replace substantive review.

27.19.22. Dual Review

High-risk judgement MAY require:

primary assessor;
second assessor;
independent reviewer;
consensus or adjudication rule;
dissent preservation;
provenance.

27.19.23. Assessor Disagreement

Disagreement SHALL preserve:

issue;
evidence;
positions;
rationales;
adjudicator;
outcome;
minority view;
provenance.

27.19.24. Legal Judgement

Legal judgement SHALL identify:

jurisdiction;
source authority;
issue;
interpretation;
uncertainty;
external counsel where used;
limitation;
effect on conformance;
provenance.

It SHALL not be generated solely by an AI agent.

27.19.25. Methodology Judgement

Methodology judgement SHALL evaluate:

authority;
scope;
boundary;
assumptions;
factors;
allocation;
uncertainty;
comparability;
limitations;
provenance.

27.19.26. Security Judgement

Security judgement SHALL evaluate:

threat model;
trust boundaries;
controls;
residual risk;
tenant impact;
exploitability;
detection;
response;
provenance.

27.19.27. Tenant-Isolation Judgement

Tenant-isolation judgement SHALL consider:

technical partitioning;
authority;
data paths;
graph paths;
event routing;
agent context;
shared services;
logs;
backups;
incident history;
provenance.

27.19.28. Publication Judgement

Publication judgement SHALL evaluate:

claim scope;
audience;
disclosure;
completeness;
balance;
assurance;
certification status;
limitations;
historical accuracy;
provenance.

27.19.29. Remote Assessment

Remote assessment SHALL identify limitations concerning:

observation;
physical access;
system access;
evidence authenticity;
interview control;
jurisdiction;
security;
tenant confidentiality.

27.19.30. On-Site Assessment

On-site assessment SHALL define:

site;
authority;
access;
safety;
confidentiality;
systems;
evidence;
data handling;
visit record;
provenance.

27.19.31. Language and Translation

Where assessment uses translation, the record SHALL preserve:

source language;
target language;
translator;
competence;
version;
ambiguity;
review;
provenance.

27.19.32. Accessibility

Assessment methods SHOULD support assessors and participants with relevant accessibility needs without weakening evidence or independence.

27.19.33. Sensitive Interview Protection

Sensitive interviews MAY require:

protected identity;
anti-retaliation controls;
restricted evidence;
independent channel;
corroboration;
controlled disclosure.

27.19.34. Manual Finding

A Manual Finding SHALL identify:

assessor;
competence;
Criterion;
evidence;
judgement rubric;
observed state;
severity;
materiality;
uncertainty;
rationale;
review;
provenance.

27.19.35. Manual Assessment Receipt

A receipt SHOULD contain:

Plan;
methods;
assessors;
competence;
independence;
inspections;
interviews;
observations;
judgements;
Findings;
review;
provenance.

27.19.36. Manual Assessment Validation

HECATE SHALL validate objective structure including:

Plan;
assessor identity;
authority;
competence evidence;
independence;
evidence references;
rubric;
review;
provenance.

HECATE SHALL not replace the authorised expert judgement itself.

27.20. Sampling, Materiality, Confidence and Uncertainty

Sampling SHALL support proportionate assessment where full-population testing is unnecessary, impractical or less effective.

Sampling SHALL not conceal population gaps, tenant variation, rare critical events or systemic risk.

27.20.1. Sampling Plan

Every material sample-based assessment SHALL possess:

Sampling Plan Identifier;
assessment;
population;
sampling unit;
sampling frame;
method;
strata;
period;
sample size;
selection procedure;
confidence objective;
tolerable deviation;
expected deviation;
materiality;
expansion rules;
limitations;
owner;
approval;
provenance.

27.20.2. Population Definition

A population SHALL identify:

subject class;
start and end;
data source;
completeness;
tenant scope;
white-label scope;
Module scope;
Component scope;
Extension scope;
inclusion rules;
exclusion rules;
provenance.

27.20.3. Sampling Unit

A Sampling Unit MAY be:

object;
transaction;
event;
workflow;
Task;
decision;
calculation;
Publication;
tenant;
site;
user;
Component execution;
time interval;
Control operation;
evidence item.

27.20.4. Sampling Frame

The frame SHALL identify the list or mechanism from which samples are selected.

Frame incompleteness SHALL be treated as a limitation or Finding.

27.20.5. Full-Population Testing

Full-population testing MAY be preferred where:

automation is reliable;
population is accessible;
criticality is high;
rare exceptions are material;
complete event history exists;
tenant-isolation risk requires exhaustive analysis.

Full-population processing SHALL not guarantee semantic completeness.

27.20.6. Statistical Sampling

Statistical sampling SHALL identify:

method;
assumptions;
confidence;
precision;
expected deviation;
tolerable deviation;
population size;
selection procedure;
evaluation method;
provenance.

27.20.7. Non-Statistical Sampling

Non-statistical sampling SHALL identify:

selection rationale;
risk factors;
coverage;
limitations;
prohibition on unsupported statistical inference;
provenance.

27.20.8. Random Sampling

Random sampling SHALL use a reproducible or recorded selection mechanism.

27.20.9. Systematic Sampling

Systematic sampling SHALL identify:

interval;
starting point;
population ordering;
periodicity risk;
provenance.

27.20.10. Stratified Sampling

Strata MAY include:

tenant;
white-label deployment;
jurisdiction;
Module;
Component;
Extension;
environment;
risk level;
transaction value;
Publication class;
time period.

27.20.11. Risk-Based Sampling

Risk-based sampling MAY prioritise:

prior Findings;
incidents;
high-value transactions;
rare but critical events;
privileged actions;
cross-tenant operations;
manual overrides;
late adjustments;
model anomalies;
Publication corrections.

27.20.12. Judgemental Sampling

Judgemental selection SHALL preserve:

selection rationale;
assessor competence;
risk basis;
limitations;
provenance.

27.20.13. Continuous Sampling

Continuous sampling MAY use:

rolling windows;
event triggers;
threshold triggers;
adaptive frequency;
stratified rotation;
tenant rotation;
Component rotation.

27.20.14. Adaptive Sampling

Adaptive sampling MAY expand or redirect based on observed deviations.

The expansion rule SHALL be defined or governed.

27.20.15. Sample Size

Sample size SHALL consider:

population;
confidence;
tolerable deviation;
expected deviation;
subject variability;
criticality;
tenant diversity;
control frequency;
evidence reliability;
prior Findings.

27.20.16. Small Population

For small critical populations, full-population testing SHOULD be considered.

27.20.17. Rare Critical Event

A rare critical event SHALL not be excluded merely because random sampling is unlikely to select it.

Targeted procedures SHOULD address it.

27.20.18. Tenant Sampling

Tenant sampling SHALL account for:

tenant size;
jurisdiction;
active Extensions;
white-label operator;
data residency;
shared Components;
risk;
incident history;
Publication activity.

27.20.19. Multi-Tenant Fairness

A sample SHALL not overrepresent large tenants while concealing material issues in small or specialised tenants.

27.20.20. White-Label Sampling

White-label sampling SHALL account for:

operator configuration;
tenant population;
operator Extensions;
public branding;
shared services;
support model;
jurisdictions.

27.20.21. Module and Component Sampling

Sampling SHALL preserve:

Module identity;
Component identity;
version;
execution population;
tenant population;
risk;
common dependencies;
provenance.

27.20.22. Time Sampling

Time sampling SHALL consider:

reporting period;
peak period;
close period;
migration period;
incident period;
maintenance period;
low-volume period;
timezone;
effective-time change.

27.20.23. Sample Substitution

Substitution SHALL be governed.

A selected item SHALL not be replaced merely because evidence is difficult or a deviation is suspected.

27.20.24. Missing Sample Item

A missing item SHALL be classified as:

validly unavailable;
evidence gap;
population defect;
Control failure;
potential concealment;
subject to replacement under approved rule.

27.20.25. Deviation

A sampled deviation SHALL identify:

item;
Criterion;
expected state;
observed state;
severity;
cause;
population relevance;
provenance.

27.20.26. Deviation Rate

A deviation rate SHALL identify:

numerator;
denominator;
weighting;
strata;
confidence;
extrapolation;
limitations;
provenance.

27.20.27. Tolerable Deviation

Tolerable deviation SHALL not permit failure of a zero-tolerance constitutional or tenant-isolation requirement.

27.20.28. Sample Expansion

Expansion MAY be required where:

observed deviation exceeds expectation;
a critical deviation appears;
systemic cause is suspected;
population completeness is uncertain;
tenant concentration appears;
evidence quality is weak;
assessor judgement requires.

27.20.29. Extrapolation

Extrapolation SHALL identify:

method;
population;
confidence;
projected deviation;
limitations;
materiality;
provenance.

27.20.30. Zero Exceptions

Zero observed deviations SHALL not prove zero population deviations unless the method supports that conclusion.

27.20.31. Materiality Framework

Every assessment SHOULD possess a Materiality Framework defining:

materiality dimensions;
thresholds;
qualitative overrides;
subject criticality;
requirement severity;
aggregation;
tenant treatment;
Publication treatment;
authority;
provenance.

27.20.32. Quantitative Materiality

Quantitative materiality MAY consider:

absolute amount;
percentage;
frequency;
duration;
population affected;
number of tenants;
number of Publications;
operational downtime;
data volume.

27.20.33. Qualitative Materiality

An issue MAY be material regardless of amount where it affects:

constitutional authority;
Protected Invariant;
tenant isolation;
personal data;
fraud or manipulation;
regulator requirement;
public claim;
identity integrity;
evidence integrity;
certification integrity;
historical truth.

27.20.34. Aggregation of Small Deviations

Individually small deviations MAY become material through:

common cause;
repeated pattern;
tenant concentration;
period concentration;
Module concentration;
Component concentration;
cumulative effect;
public-claim effect.

27.20.35. Confidence Statement

Every sample-based conclusion SHOULD state:

population;
method;
sample size;
confidence;
tolerable deviation;
observed deviation;
inference;
limitations;
provenance.

27.20.36. Uncertainty Classes

Uncertainty MAY arise from:

missing evidence;
measurement error;
sampling error;
model uncertainty;
judgement uncertainty;
temporal mismatch;
subject change;
external dependency;
translation;
historical reconstruction.

27.20.37. Uncertainty Record

An Uncertainty Record SHALL identify:

source;
affected Criterion;
magnitude or class;
probability where appropriate;
impact;
mitigation;
Outcome effect;
provenance.

27.20.38. Confidence Classification

Confidence MAY be:

Very High;
High;
Moderate;
Low;
Very Low;
Indeterminate.

A confidence label SHALL not conceal an adverse Finding.

27.20.39. Conservative Treatment

Where uncertainty affects a critical requirement, the assessment SHOULD apply conservative treatment or escalate.

27.20.40. Sampling Receipt

A receipt SHOULD contain:

Sampling Plan;
population;
frame;
method;
sample;
deviations;
expansion;
materiality;
confidence;
limitations;
provenance.

27.20.41. Sampling Validation

HECATE SHALL validate:

Plan;
population;
frame;
selection;
tenant and white-label coverage;
sample size metadata;
deviation calculation;
expansion rule;
materiality;
confidence statement;
provenance.

27.21. Finding Adjudication, Root Cause and Systemic Analysis

A Finding SHALL move through a governed lifecycle from preliminary observation to final classification, remediation, exception, closure, supersession or withdrawal.

Finding adjudication SHALL preserve evidence, assessor reasoning, assessed-party response, disagreement, reclassification and Outcome effect.

27.21.1. Finding Lifecycle

Finding lifecycle states MAY include:

Detected;
Preliminary;
Evidence Review;
Assessed-Party Response;
Under Adjudication;
Confirmed;
Reclassified;
Duplicate;
Consolidated;
Remediation Planned;
Remediation in Progress;
Awaiting Validation;
Closed;
Closed with Residual Risk;
Accepted Exception;
Reopened;
Withdrawn as Erroneous;
Superseded;
Historical.

27.21.2. Preliminary Observation

A preliminary observation SHALL identify:

assessment;
subject;
Criterion;
observed state;
initial evidence;
potential severity;
assessor;
uncertainty;
next action;
provenance.

It SHALL not be published as a final Finding unless the governing profile permits.

27.21.3. Finding Confirmation

Confirmation SHALL require:

subject identity;
Snapshot;
applicable requirement;
Criterion;
sufficient evidence;
observed and expected state;
severity;
materiality;
affected scope;
assessor authority;
review where required;
provenance.

27.21.4. Finding Classification

Classification SHALL distinguish:

requirement failure;
Control design deficiency;
Control implementation deficiency;
Control operating deficiency;
evidence deficiency;
applicability deficiency;
tenant-isolation deficiency;
security deficiency;
Runtime deficiency;
Module deficiency;
Component deficiency;
Extension deficiency;
Publication deficiency;
assurance deficiency;
certification-process deficiency;
historical-trust deficiency.

27.21.5. Finding Severity Matrix

Severity SHOULD consider:

normative force;
subject criticality;
impact magnitude;
population affected;
tenant exposure;
white-label exposure;
legal or regulatory exposure;
security exploitability;
Publication exposure;
duration;
recurrence;
reversibility;
detection capability;
evidence confidence.

27.21.6. Zero-Tolerance Finding

A zero-tolerance Finding MAY include:

active cross-tenant leakage;
falsified evidence;
invalid certification authority;
prohibited identity reuse;
unratified Core override;
materially misleading certification claim;
compromised signing key;
deliberate suppression of critical Findings.

A zero-tolerance Finding SHALL not be offset by aggregate scoring.

27.21.7. Finding Materiality Decision

Every materiality decision SHALL identify:

Finding;
Materiality Framework;
quantitative factors;
qualitative factors;
aggregation;
affected claims;
decision maker;
rationale;
provenance.

27.21.8. Finding Confidence Decision

Confidence SHALL be supported by:

evidence quality;
evidence consistency;
method;
sample;
reproducibility;
expert judgement;
unresolved conflict;
provenance.

27.21.9. Affected Scope

Affected scope SHALL identify as applicable:

Baseline;
Profile;
tenant;
white-label deployment;
organisation;
Module;
Component;
Extension;
Runtime Bundle;
Runtime Manifest;
environment;
period;
Publication;
certification scope.

27.21.10. Duplicate Finding

A duplicate SHALL preserve:

original Finding;
duplicate Finding;
relationship;
distinct evidence;
distinct subjects;
consolidation decision;
provenance.

Related Findings MAY share:

requirement;
Control;
root cause;
Component;
Module;
tenant;
Extension;
evidence source;
period;
remediation.

27.21.12. Consolidated Finding

A Consolidated Finding SHALL preserve all constituent Findings and SHALL not erase subject-specific severity or evidence.

27.21.13. Systemic Finding

A Systemic Finding SHALL identify:

systemic cause;
affected requirements;
affected Controls;
affected Modules;
affected Components;
affected Extensions;
affected tenants and white-label deployments;
affected periods;
affected Publications;
common evidence;
remediation scope;
provenance.

27.21.14. Root-Cause Analysis

Root-cause analysis SHALL distinguish:

immediate cause;
contributing cause;
systemic cause;
control failure;
governance failure;
authority failure;
evidence failure;
detection failure;
organisational factor;
technical factor;
external factor.

27.21.15. Root-Cause Methods

Methods MAY include:

causal graph;
event timeline;
five-whys analysis;
fault-tree analysis;
barrier analysis;
change analysis;
control-path analysis;
dependency-graph analysis;
incident replay;
comparative analysis.

27.21.16. Causal Graph

A causal graph SHOULD identify:

Finding;
triggering event;
conditions;
failed Controls;
failed dependencies;
actors;
Modules;
Components;
Extensions;
tenants;
outcomes;
confidence;
provenance.

27.21.17. Common-Cause Failure

A common-cause failure SHALL evaluate whether apparently independent Controls depend on the same:

Component;
Module;
data source;
credential;
model;
tool;
provider;
administrator;
workflow;
evidence system.

27.21.18. Control Failure Classification

A Control failure MAY be:

absent;
incorrectly designed;
not implemented;
partially implemented;
incorrectly configured;
not operated;
operated inconsistently;
overridden;
bypassed;
not monitored;
not evidenced;
ineffective.

27.21.19. Detection Failure

A Finding SHOULD evaluate why existing monitoring, testing or review did not detect the issue earlier.

27.21.20. Impact Analysis

Finding impact analysis SHALL cover as applicable:

prior Conformance Outcomes;
active Certificates;
Runtime Admissions;
active Runtime state;
tenant operations;
white-label operations;
Extension compatibility;
decisions;
calculations;
workflows;
events;
agent actions;
tool actions;
Publications;
assurance;
historical records.

27.21.21. Affected-Outcome Analysis

Where a Finding may invalidate prior results, the assessment SHALL identify:

affected subject Snapshots;
affected assessment periods;
affected Outcomes;
affected Certificates;
affected public claims;
required reassessment;
correction or withdrawal;
provenance.

27.21.22. Assessed-Party Response

A response SHALL identify:

agreement or disagreement;
additional evidence;
alternative interpretation;
root-cause view;
remediation proposal;
requested severity or scope change;
representative;
time;
provenance.

27.21.23. Assessor Response

The assessor SHALL document:

response considered;
evidence considered;
accepted changes;
rejected arguments;
final classification;
rationale;
provenance.

27.21.24. Finding Adjudicator

The adjudicator SHALL possess:

authority;
competence;
independence appropriate to the Finding;
access to evidence;
conflict disclosure;
provenance.

27.21.25. Finding Adjudication Decision

Every decision SHALL possess:

Adjudication Identifier;
Finding;
evidence set;
parties' positions;
applicable requirement;
classification;
severity;
materiality;
confidence;
scope;
decision;
rationale;
appeal path;
provenance.

27.21.26. Reclassification

Reclassification SHALL preserve:

prior classification;
target classification;
evidence;
reason;
decision authority;
Outcome impact;
time;
provenance.

27.21.27. Finding Withdrawal

A Finding may be withdrawn where it was erroneous.

Withdrawal SHALL preserve:

original Finding;
error;
evidence;
authority;
affected reports or Outcomes;
correction;
provenance.

27.21.28. Finding Suppression Prohibition

A Finding SHALL not be hidden, deleted, downgraded or excluded because it is:

commercially inconvenient;
politically sensitive;
certification-blocking;
difficult to remediate;
raised by a minority assessor;
detected by an automated system;
limited to one tenant.

27.21.29. Risk Acceptance

Risk acceptance SHALL remain distinct from conformance.

Every Risk Acceptance SHALL identify:

Finding;
risk;
authority;
scope;
reason;
compensating Controls;
duration;
monitoring;
residual risk;
effect on Outcome;
effect on certification;
provenance.

27.21.30. Exception Versus Risk Acceptance

An Exception governs permitted deviation from a requirement where authority exists.

Risk Acceptance acknowledges residual risk.

Neither SHALL automatically convert non-conformance into conformance.

27.21.31. Finding Notification

Notification MAY be required for:

subject owner;
Module owner;
Component owner;
tenant;
white-label operator;
Extension publisher;
Security Runtime;
Runtime Admission Authority;
Publication Authority;
assurance provider;
certification body;
regulator.

27.21.32. Finding Registry

The Finding Registry SHALL preserve:

identities;
subjects;
requirements;
evidence;
classifications;
severity;
materiality;
scope;
adjudication;
remediation;
exceptions;
closure;
history;
provenance.

27.21.33. Finding Receipt

A receipt SHOULD contain:

Finding;
subject;
Snapshot;
requirement;
evidence;
classification;
severity;
materiality;
confidence;
scope;
adjudication;
Outcome effect;
provenance.

27.21.34. Finding Validation

HECATE SHALL validate:

Finding identity;
subject and Snapshot;
requirement;
evidence linkage;
classification;
severity metadata;
scope;
adjudication;
reclassification;
risk acceptance;
Registry state;
provenance.

27.22. Remediation, Reassessment and Finding Closure

Remediation SHALL restore or establish conformant state, contain risk, correct evidence, improve Controls or resolve assessment deficiencies.

Remediation SHALL not erase the original Finding or the state that caused it.

27.22.1. Remediation Programme

A Remediation Programme MAY coordinate related Findings across:

requirements;
Controls;
Modules;
Components;
Extensions;
tenants;
white-label deployments;
Runtime environments;
Publications;
certification scopes.

27.22.2. Remediation Programme Identity

Every material Programme SHALL possess:

Programme Identifier;
included Findings;
root causes;
affected subjects;
affected tenants;
affected Modules and Components;
owner;
sponsor;
authority;
target state;
schedule;
risk;
dependencies;
validation strategy;
lifecycle;
provenance.

27.22.3. Remediation Plan

Every material Finding SHALL possess or reference a Remediation Plan containing:

Remediation Identifier;
Finding;
root cause;
corrective objective;
actions;
owner;
supporting owners;
target date;
interim controls;
dependencies;
change-control requirements;
validation method;
operating-effectiveness period;
rollback or recovery;
closure authority;
provenance.

27.22.4. Remediation Action Classes

Action Classes MAY include:

containment;
data correction;
graph correction;
identity correction;
configuration correction;
code correction;
schema correction;
policy correction;
decision-logic correction;
methodology correction;
workflow correction;
event correction;
agent correction;
model correction;
tool correction;
Module reassignment;
Component correction;
Extension correction;
evidence correction;
process correction;
training;
access revocation;
key rotation;
Publication correction;
certification-claim correction;
Corrective Amendment where Core meaning is defective.

27.22.5. Containment

Containment MAY include:

disable capability;
isolate tenant;
suspend Component;
suspend Extension;
block Runtime Admission;
block Publication;
revoke access;
preserve evidence;
activate fallback;
add monitoring.

Containment SHALL not be represented as complete remediation unless the target state requires only containment.

27.22.6. Corrective Action

Corrective action addresses the detected non-conformity.

27.22.7. Preventive Action

Preventive action addresses recurrence or similar risk in other subjects.

27.22.8. Interim Control

An interim Control SHALL identify:

requirement;
temporary implementation;
owner;
evidence;
effective time;
expiration;
limitations;
monitoring;
provenance.

27.22.9. Remediation Authority

Remediation authority SHALL distinguish:

authority to change implementation;
authority to change configuration;
authority to change tenant state;
authority to change Extension state;
authority to correct Publication;
authority to change Core meaning.

Core meaning changes SHALL use Constitutional Evolution.

27.22.10. Remediation Change Control

A material remediation SHALL follow governed change control including:

change request;
impact analysis;
approval;
implementation;
testing;
migration;
deployment;
monitoring;
rollback;
provenance.

27.22.11. Cross-Tenant Remediation

A shared remediation SHALL identify:

affected tenant population;
common Component;
tenant-specific differences;
migration waves;
tenant isolation;
communication;
validation;
provenance.

27.22.12. White-Label Remediation

White-label remediation SHALL additionally address:

operator approval;
operator Extensions;
branded Publications;
shared services;
tenant population;
support;
provenance.

27.22.13. Module Remediation

Module remediation SHALL identify:

constitutional responsibility;
affected capabilities;
affected Components;
data and event ownership;
workflow ownership;
external contracts;
owner;
validation;
provenance.

27.22.14. Component Remediation

Component remediation SHALL identify:

Component;
owning Module;
version;
affected contract;
state migration;
deployment;
tenant routing;
rollback;
validation;
provenance.

27.22.15. Extension Remediation

Extension remediation SHALL identify:

Extension;
Package;
Extension Point;
Namespace;
tenant scope;
recompile;
revalidation;
migration;
repackaging;
activation;
provenance.

27.22.16. Publication Remediation

Publication remediation MAY require:

correction;
restatement;
supersession;
withdrawal;
public notice;
assurance modification;
certification-claim modification.

It SHALL comply with the CPF.

27.22.17. Evidence Remediation

Evidence remediation MAY include:

corrected extraction;
expanded population;
refreshed evidence;
restored chain of custody;
corrected classification;
tenant resegregation;
new signature;
invalidation of compromised evidence.

27.22.18. Remediation Evidence Package

Every material remediation SHOULD produce a Package containing:

original Finding;
original state;
remediation actions;
changed artefacts;
change approvals;
target state;
Test Executions;
operating-effectiveness evidence;
residual risk;
provenance.

27.22.19. Reassessment Plan

Reassessment SHALL identify:

Findings assessed;
affected Criteria;
affected subject Snapshot;
methods;
evidence;
Tests;
sampling;
assessor;
independence;
period;
Outcome effect;
provenance.

27.22.20. Remediation Test

A remediation Test SHALL verify whether the specific detected issue is corrected.

27.22.21. Regression Test

Regression testing SHALL evaluate whether remediation introduced adverse effects in:

related requirements;
Controls;
Modules;
Components;
Extensions;
tenants;
workflows;
events;
agents;
Publications.

27.22.22. Operating-Effectiveness Period

Where a Control requires repeated operation, closure SHALL require sufficient operating-effectiveness evidence over a defined period.

Implementation at one point in time SHALL not establish sustained effectiveness.

27.22.23. Immediate Closure

Immediate closure MAY be permitted for a point-in-time defect where:

correction is objectively verifiable;
no operating period is required;
affected outcomes are treated;
authority permits;
provenance is complete.

27.22.24. Partial Remediation

Partial remediation SHALL identify:

corrected scope;
remaining scope;
residual Finding;
residual risk;
Outcome effect;
target date;
provenance.

27.22.25. Remediation Failure

Failure SHALL preserve:

attempted action;
expected state;
observed state;
cause;
affected subjects;
side effects;
rollback;
revised Plan;
provenance.

27.22.26. Overdue Remediation

Overdue remediation SHALL trigger according to profile:

escalation;
reassessment;
Outcome modification;
Runtime restriction;
Certificate condition;
suspension;
withdrawal;
Publication update.

27.22.27. Closure Criteria

Closure SHALL require:

target state achieved;
remediation evidence sufficient;
required Tests passed;
regression impact treated;
operating effectiveness demonstrated where required;
affected Outcomes reassessed;
affected Certificates treated;
closure authority valid;
provenance complete.

27.22.28. Closure Decision

Every closure decision SHALL possess:

Closure Decision Identifier;
Finding;
remediation;
reassessment;
evidence;
residual risk;
decision;
closure authority;
time;
provenance.

27.22.29. Closed with Residual Risk

This state SHALL identify:

residual issue;
risk;
authority;
monitoring;
expiration or review;
Outcome effect;
certification effect;
provenance.

27.22.30. Finding Reopening

A Finding SHALL reopen where:

remediation proves ineffective;
issue recurs;
evidence was invalid;
subject changes;
broader scope is discovered;
incident occurs;
challenge succeeds;
audit identifies premature closure.

27.22.31. Recurrence Analysis

Recurrence SHALL evaluate:

prior Finding;
prior root cause;
prior remediation;
failed preventive action;
affected Modules and Components;
governance failure;
systemic escalation;
provenance.

27.22.32. Outcome Reassessment

Closure or remediation MAY change a Conformance Outcome only through a new governed Outcome Decision.

27.22.33. Certification Impact

Remediation SHALL identify whether certification may be:

granted;
maintained;
conditioned;
scope-reduced;
suspended;
withdrawn;
renewed;
unchanged.

The certification body SHALL make the Certification Decision.

27.22.34. Runtime Impact

Remediation SHALL identify whether Runtime state may be:

admitted;
reactivated;
unrestricted;
kept under condition;
held;
rolled back;
migrated.

27.22.35. Remediation Registry

The Remediation Registry SHALL preserve:

Programmes;
Plans;
actions;
owners;
evidence;
Tests;
reassessments;
failures;
closures;
reopenings;
provenance.

27.22.36. Remediation Receipt

A receipt SHOULD contain:

Finding;
Plan;
actions;
original state;
target state;
evidence Package;
reassessment;
closure;
residual risk;
Outcome effect;
provenance.

27.22.37. Remediation Validation

HECATE SHALL validate:

Plan;
authority;
action identity;
affected Module and Component;
change-control evidence;
remediation evidence;
Tests;
operating-effectiveness period;
closure criteria;
reopening;
provenance.

27.23. Assessment Package, Reporting and Decision Support

An Assessment Package is the integrity-protected collection of assessment artefacts required to understand, review, reproduce and rely upon a Conformance Outcome or downstream assurance or Certification Decision.

An Assessment Package SHALL support a decision.

It SHALL not create authority by assembly or presentation.

27.23.1. Assessment Package Identity

Every Assessment Package SHALL possess:

Package Identifier;
assessment;
subject;
Subject Snapshot;
Baseline;
Profiles;
Scope Manifest;
Conformance Traceability Matrix;
Evidence Package inventory;
Test Execution inventory;
Finding inventory;
exception inventory;
remediation inventory;
draft or final Outcome;
Package Manifest;
lifecycle;
version;
digest;
provenance.

27.23.2. Assessment Package Types

Types MAY include:

Planning Package;
Interim Assessment Package;
Finding Review Package;
Remediation Package;
Final Assessment Package;
Certification Review Package;
Surveillance Package;
Historical Assessment Package;
Public Conformance Package;
Restricted Regulator Package.

27.23.3. Package Manifest

The Manifest SHALL identify:

Package;
subject;
Snapshot digest;
Baseline;
Profile versions;
Scope Manifest digest;
CTM digest;
Evidence Package digests;
Test Execution records;
Findings;
exceptions;
remediation;
Outcome;
signatures;
classification;
provenance.

27.23.4. Package Completeness

Completeness SHALL be evaluated across:

subject identity;
scope;
applicability;
requirement coverage;
evidence;
Tests;
Findings;
exceptions;
remediation;
review;
Outcome derivation;
limitations;
provenance.

27.23.5. Package Freeze

The final Package SHALL be frozen before Outcome review or certification review.

A material change SHALL create:

new Package version;
impact analysis;
renewed review;
updated signatures;
provenance.

27.23.6. Package Integrity

Integrity SHOULD be protected through:

canonical Manifest;
content digests;
artefact-root digest;
trusted timestamp;
signatures;
immutable storage;
provenance.

27.23.7. Assessment Report

An Assessment Report is a governed projection of the Assessment Package for a defined audience.

The Package remains the authoritative assessment collection.

27.23.8. Report Types

Report Types MAY include:

Full Technical Assessment Report;
Executive Assessment Report;
Management Report;
Certification Review Report;
Regulator Report;
Tenant Report;
White-Label Operator Report;
Public Conformance Statement;
Remediation Report;
Surveillance Report;
Historical Verification Report.

27.23.9. Report Content

A full report SHOULD contain:

report identity;
assessment purpose;
subject;
Snapshot;
Baseline;
Profile;
scope;
exclusions;
methods;
evidence summary;
requirement coverage;
Findings;
exceptions;
remediation;
limitations;
Outcome;
validity;
assessor;
review;
provenance reference.

27.23.10. Executive Summary

An executive summary SHALL not omit:

material scope limitations;
critical Findings;
unresolved conditions;
partial conformance;
Indeterminate areas;
validity limits;
certification distinction.

27.23.11. Technical Annex

A Technical Annex MAY include:

CTM;
detailed Test Executions;
evidence inventory;
sampling;
assessor judgements;
root-cause analysis;
remediation verification;
Module and Component lineage;
Extension lineage;
tenant coverage;
provenance.

27.23.12. Scope Statement

The scope statement SHALL identify:

included subjects;
excluded subjects;
dependencies;
inherited Controls;
tenants;
white-label deployments;
Modules;
Components;
Extensions;
environments;
periods;
jurisdictions.

27.23.13. Method Statement

The method statement SHALL identify:

assessment methods;
automation;
manual review;
sampling;
replay;
materiality;
confidence;
limitations.

27.23.14. Evidence Statement

The evidence statement SHALL identify:

Evidence Classes;
evidence period;
integrity;
freshness;
sampling;
gaps;
restricted evidence;
controlled redaction;
limitations.

27.23.15. Finding Presentation

Findings SHALL be presented with:

identity;
requirement;
subject;
observed state;
expected state;
severity;
materiality;
scope;
status;
remediation;
provenance reference.

27.23.16. Outcome Presentation

Outcome presentation SHALL distinguish:

Conformant;
Conformant with Conditions;
Partially Conformant;
Non-Conformant;
Indeterminate;
Not Evaluated.

Visual design SHALL not make a limited or conditional Outcome appear unconditional.

27.23.17. Certification Decision Support

A Certification Review Package SHALL contain:

valid final Assessment Package;
applicant;
Scheme;
certified subject request;
scope;
Conformance Outcome;
critical Findings;
conditions;
exceptions;
surveillance recommendation;
claim recommendation;
limitations;
provenance.

It SHALL not contain an implied Certification Decision before authority acts.

27.23.18. Assurance Decision Support

An assurance-support Package SHALL identify:

assurance subject matter;
criteria;
evidence;
assessment work;
independence limitations;
Findings;
period;
provenance.

The assurance provider SHALL determine the assurance conclusion.

27.23.19. Runtime Decision Support

A Runtime Admission Package MAY contain:

Baseline;
Runtime Bundle;
Runtime Manifest;
critical conformance results;
security evidence;
tenant-isolation evidence;
Extension compatibility;
unresolved Findings;
conditions;
provenance.

27.23.20. Publication Decision Support

A Publication decision-support Package MAY contain:

source Outcome;
assessment scope;
certification status;
assurance status;
permitted claim;
disclosure limitations;
validity;
correction state;
provenance.

27.23.21. Audience Profile

Every report SHALL identify its Audience Profile, such as:

internal governance;
technical team;
tenant;
white-label operator;
certification body;
assurance provider;
regulator;
public.

27.23.22. Disclosure Profile

The Disclosure Profile SHALL define:

public content;
restricted content;
tenant-specific content;
security-sensitive content;
privileged content;
redaction;
aggregation;
verification.

27.23.23. Controlled Redaction

A redacted report SHALL preserve:

source Package;
redaction rule;
redacted elements;
authority;
effect on interpretation;
controlled-access path;
source and target digests;
provenance.

27.23.24. Multi-Tenant Reporting

Multi-tenant reporting SHALL prevent disclosure of:

tenant identities;
tenant data;
tenant Findings;
tenant configuration;
tenant Extensions

unless authorised.

Aggregate reports SHALL preserve the ability to identify tenant-specific systemic risk under controlled access.

27.23.25. White-Label Reporting

White-label reporting SHALL preserve:

operator identity;
tenant population;
shared Components;
operator Extensions;
branded claims;
operator-specific Findings;
disclosure authority.

27.23.26. Report Signature

A report signature SHALL bind:

report identity;
source Package digest;
subject;
scope;
Outcome;
signer;
Role;
time;
key;
provenance.

27.23.27. Package Signature

A Package signature MAY bind:

Manifest digest;
artefact-root digest;
assessment owner;
Lead Assessor;
independent reviewer;
time;
key;
provenance.

Each signature SHALL identify its scope.

27.23.28. Report Release

Release SHALL require:

final Package;
approved report projection;
correct Audience and Disclosure Profiles;
valid authority;
signatures where required;
CPF eligibility;
provenance.

27.23.29. Report Correction

An erroneous report SHALL be corrected through a new governed report version or correction record.

The original SHALL remain historically preserved.

27.23.30. Report Restatement

A material change to scope, evidence, Findings or Outcome SHALL require restatement rather than editorial correction.

27.23.31. Report Supersession

A report MAY be superseded by:

corrected assessment;
reassessment;
surveillance assessment;
recertification;
changed Baseline;
changed subject Snapshot.

Supersession SHALL preserve lineage.

27.23.32. Report Withdrawal

A report MAY be withdrawn where:

assessment was invalid;
evidence was falsified;
authority was invalid;
subject identity was wrong;
scope was materially misleading;
integrity was compromised.

Withdrawal SHALL comply with the CPF.

27.23.33. Assessment Challenge

An authorised party MAY challenge:

scope;
applicability;
method;
evidence;
sampling;
Finding;
severity;
materiality;
Outcome;
report accuracy.

27.23.34. Package Archive

The archive SHALL preserve:

Package;
Manifest;
report projections;
digests;
signatures;
evidence references;
Findings;
corrections;
restatements;
supersession;
withdrawal;
provenance.

27.23.35. Public Verification

A public verification service MAY expose:

report or Outcome identity;
subject;
scope;
Baseline;
Profile;
status;
issue time;
validity;
supersession;
withdrawal;
digest;
signature state;
provenance summary.

27.23.36. Assessment Package Receipt

A receipt SHOULD contain:

Package;
Manifest digest;
artefact-root digest;
subject;
Snapshot;
Baseline;
scope;
evidence inventory;
Finding inventory;
Outcome;
signatures;
lifecycle;
provenance.

27.23.37. Package and Reporting Validation

HECATE SHALL validate:

Package identity;
Manifest;
completeness;
freeze;
integrity;
report binding;
scope statement;
Outcome presentation;
disclosure;
redaction;
signatures;
correction and withdrawal state;
provenance.

27.24. Part II Provenance, Metrics and Integrated Conformance

Part II SHALL preserve complete assessment-engineering lineage from Programme and subject discovery through evidence, testing, Finding adjudication, remediation and final Assessment Package.

27.24.1. Part II Provenance

Part II provenance SHALL include:

Assessment Programme;
Programme Charter;
Assessment Portfolio;
assessment dependencies;
independence model;
competence model;
Subject Discovery Plan;
inventories;
Scope Manifest;
Subject Snapshots;
Conformance Traceability Matrix;
requirement mappings;
Control mappings;
Test mappings;
Evidence Plan;
Evidence Requests;
Evidence Objects;
Evidence Packages;
chain of custody;
Test Suites;
Test Specifications;
Test Fixtures;
Test Oracles;
Test Executions;
automated validations;
manual assessments;
sampling;
materiality;
uncertainty;
Findings;
adjudication;
root cause;
Remediation Plans;
reassessment;
closure;
Assessment Package;
Assessment Reports;
Module lineage;
Component lineage;
Extension lineage;
tenant lineage;
white-label lineage;
Publication lineage;
temporal lineage.

27.24.2. Part II Provenance Graph

Assessment Portfolio and Programme
        │
        ▼
Subject Discovery and Inventory
        │
        ├── Tenant and White-Label Scope
        ├── Module Inventory
        ├── Component Inventory
        ├── Extension Inventory
        └── Dependency Inventory
        │
        ▼
Scope Manifest and Subject Snapshot
        │
        ▼
Conformance Traceability Matrix
        │
        ├── Requirements
        ├── Controls
        ├── Criteria
        ├── Tests
        └── Evidence Requirements
        │
        ▼
Evidence Plan and Evidence Packages
        │
        ▼
Test Engineering and Assessment Execution
        │
        ├── Automated Validation
        ├── Manual Inspection
        ├── Expert Judgement
        ├── Sampling
        └── Replay
        │
        ▼
Findings and Adjudication
        │
        ├── Root Cause
        ├── Impact
        ├── Exception
        └── Risk Acceptance
        │
        ▼
Remediation and Reassessment
        │
        ▼
Assessment Package and Reports
        │
        ▼
Outcome, Assurance and Certification Decision Support

27.24.3. Assessment Engineering History Object

A History Object SHALL preserve:

Programme versions;
scope versions;
Snapshot versions;
CTM versions;
Evidence Package versions;
Test Suite versions;
Test Execution history;
Finding history;
adjudication history;
remediation history;
Package versions;
report versions;
provenance.

27.24.4. Bitemporal Assessment Lineage

Every material assessment object SHALL preserve as applicable:

subject valid time;
Baseline effective time;
evidence valid time;
evidence transaction time;
Test Execution time;
Finding time;
adjudication time;
remediation time;
closure time;
report issue time;
archive time.

27.24.5. Assessment Engineering Metrics

Metrics MAY include:

inventory completeness;
scope-change rate;
requirement coverage;
Control coverage;
Test coverage;
evidence freshness;
evidence-gap rate;
evidence-conflict rate;
test flakiness;
false-positive rate;
false-negative rate;
automated-to-manual escalation rate;
sample deviation rate;
systemic Finding rate;
remediation ageing;
recurrence rate;
reassessment failure rate;
Package completeness;
report correction rate.

27.24.6. Metric Context

Every metric SHOULD preserve:

Programme;
assessment;
subject class;
Baseline;
Profile;
Module;
Component;
tenant or white-label scope;
Extension;
period;
provenance.

27.24.7. Metric Non-Authority

Metrics SHALL NOT independently:

determine applicability;
waive requirements;
classify a Finding finally;
accept residual risk;
close remediation;
issue a Conformance Outcome;
grant certification.

27.24.8. Assessment Quality Indicator

A quality indicator MAY identify:

design completeness;
traceability completeness;
evidence sufficiency;
Test quality;
assessor competence;
independence;
review completeness;
provenance completeness.

A quality score SHALL not conceal a critical deficiency.

27.24.9. Assessment Integrity Finding

An integrity Finding MAY arise from:

incomplete scope;
hidden dependency;
wrong Baseline;
wrong Profile;
evidence tampering;
cross-tenant evidence;
invalid Test Oracle;
assessor conflict;
Finding suppression;
premature closure;
misleading report.

27.24.10. Assessment Replay

Assessment Replay MAY reconstruct:

Programme state;
Scope Manifest;
Subject Snapshot;
Profile resolution;
CTM;
Evidence Packages;
Test Executions;
sampling;
Findings;
adjudication;
remediation;
Package;
report.

Replay SHALL not issue a new Outcome or Certification Decision without valid authority.

27.24.11. Replay Divergence

A Replay Divergence SHALL identify:

expected assessment state;
reproduced state;
affected artefact;
cause;
materiality;
Outcome impact;
limitation;
remediation;
provenance.

27.24.12. Pergamum Pulse Integration

Pergamum Pulse MAY derive intelligence including:

hidden-dependency risk;
orphan-Component risk;
scope-volatility risk;
requirement-coverage gaps;
common-Control concentration;
evidence-freshness risk;
evidence-conflict clusters;
Test flakiness;
false-negative risk;
sampling blind spots;
systemic Finding clusters;
remediation bottlenecks;
recurrence risk;
assessor-capacity risk;
Module-level conformance concentration;
Component-level conformance concentration;
tenant divergence;
white-label divergence;
Extension conformance clusters;
report-integrity risk.

Pergamum Pulse SHALL preserve:

Programme lineage;
scope lineage;
subject lineage;
Baseline lineage;
Profile lineage;
requirement lineage;
Control lineage;
evidence lineage;
Test lineage;
Finding lineage;
remediation lineage;
Package lineage;
Module lineage;
Component lineage;
Extension lineage;
tenant lineage;
white-label lineage;
Publication lineage;
temporal validity;
provenance.

Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.

27.24.13. Part II Conformance Suite

The Constitutional Compiler Framework SHOULD generate fixtures including:

valid Assessment Programme;
conflicting assessment dependencies;
invalid common-Control reuse;
valid independence model;
competence gap;
valid Subject Discovery Plan;
orphan Component;
Shadow Component;
hidden external dependency;
incomplete tenant inventory;
complete Scope Manifest;
prohibited mandatory-subject exclusion;
material post-freeze scope change;
valid CTM;
unmapped applicable requirement;
responsibility gap;
external-framework crosswalk;
critical requirement hidden by aggregate coverage;
traceability drift;
valid Evidence Plan;
read-only evidence acquisition;
controlled production evidence extraction;
cross-tenant Evidence Package;
valid Evidence Package signature;
transformed evidence with disclosed information loss;
stale evidence;
revoked evidence;
conflicting evidence;
valid Test Suite;
invalid Oracle based only on historical output;
Golden Vector;
negative Test;
boundary Test;
property-based Test;
differential Test with no authoritative Oracle;
workflow Test with side-effect isolation;
Agent Test;
tenant-isolation Test;
flaky Test;
valid automated Finding;
automation failure treated incorrectly as pass;
AI-assisted draft Finding requiring review;
valid expert judgement;
assessor self-review threat;
assessor disagreement;
valid Sampling Plan;
incomplete sampling frame;
rare critical event;
tenant sampling bias;
sample expansion;
invalid extrapolation;
qualitative materiality override;
valid systemic Finding;
Finding suppression attempt;
valid adjudication;
risk acceptance incorrectly represented as conformance;
valid Remediation Plan;
partial remediation;
insufficient operating-effectiveness period;
Finding reopening;
valid Assessment Package;
incomplete Package Manifest;
misleading executive summary;
controlled redaction;
report restatement;
report withdrawal;
complete Part II provenance.

Part II Conformance

An implementation conforms to Part II of the Core Conformance and Certification Framework where it:

governs related assessments through identifiable Assessment Programmes where coordination is required;
preserves independent subject, assessment and Outcome identity within Programmes;
maintains an Assessment Portfolio with dependencies, independence, competence, risk and lifecycle;
prevents common-Control or assessment reuse without exact scope, validity, tenant treatment and provenance;
discovers actual deployed and governed subjects rather than relying only on intended architecture;
maintains authoritative inventories of Modules, Components, Extensions, tenants, white-label deployments and Runtime state;
detects orphan Components, Shadow Components and hidden dependencies;
preserves every Component's explicit Module membership;
defines assessment boundaries through versioned Scope Manifests;
records included subjects, excluded subjects, inherited dependencies, shared Controls and claim limitations;
prevents mandatory applicable subjects from being excluded for convenience;
freezes Subject Snapshots, Scope Manifests, Profiles and requirement inventories before final execution;
governs material post-freeze change through impact analysis and reassessment;
maintains bidirectional traceability from Requirement Source to Conformance Outcome;
maps Requirements to Control Objectives, Controls, Criteria, Tests, Evidence Objects, Findings and remediation;
detects responsibility gaps, coverage gaps, conflicts and traceability drift;
prevents aggregate coverage metrics from offsetting failed critical requirements;
preserves Module and Component ownership in every material Control mapping;
governs evidence through explicit Plans, Requests, acquisition authority and minimisation;
preserves tenant and white-label isolation across evidence capture, storage, access, transformation and reporting;
preserves Evidence Package identity, Manifest, integrity, classification, freshness and chain of custody;
distinguishes direct, indirect, derived, transformed, aggregated, external and AI-analysed evidence;
prevents AI analysis from creating facts or authoritative evidence conclusions;
governs evidence expiration, revocation, conflict, retention and destruction;
represents Test Specification, Fixture, Oracle, Execution, Result and Finding as distinct objects;
derives Test Oracles from governed meaning rather than implementation precedent alone;
supports positive, negative, boundary, property-based, metamorphic, differential, replay and failure-injection testing;
supports schema, Registry, graph, policy, decision, computation, methodology, workflow, event, agent, tool, Module, Component, Extension, tenant-isolation and Publication testing;
governs test data, environments, side effects, repeatability, flakiness and versioning;
prevents test errors, blocked execution and automation failure from being treated as passing subject state;
limits automated finality to objective Criteria and approved rules;
requires HECATE to escalate unresolved judgement rather than manufacture certainty;
governs continuous conformance, change-triggered reassessment and drift detection;
preserves tenant context through automated jobs, models, caches, logs and Findings;
structures manual assessment through competent, independent and evidence-backed inspection and judgement;
records rubrics, uncertainty, disagreements, conflicts and review;
prevents AI agents from substituting for authorised legal, assurance or certification judgement;
governs sampling through explicit populations, frames, methods, sample sizes, confidence, tolerable deviation and limitations;
prevents samples from supporting claims beyond their population, period and inference;
accounts for tenant, white-label, Module, Component, Extension and temporal diversity in sampling;
applies qualitative materiality where authority, tenant isolation, evidence integrity or public claims are affected;
preserves Finding lifecycle, classification, severity, materiality, confidence, scope and adjudication;
detects systemic Findings and common-cause failures across Controls, Modules, Components and tenants;
prohibits suppression or commercial downgrading of Findings;
distinguishes exceptions, compensating Controls and Risk Acceptance from conformance;
governs remediation through Plans, change control, evidence, regression testing and operating-effectiveness periods;
preserves original non-conformant state after remediation and closure;
reopens Findings where remediation fails, evidence is invalid or recurrence occurs;
assembles immutable Assessment Packages with Manifests, digests, reports and decision-support artefacts;
prevents Assessment Packages and reports from impersonating Conformance, assurance or Certification Decisions;
governs report scope, disclosure, redaction, correction, restatement, supersession and withdrawal through the CPF;
preserves complete bitemporal Part II provenance;
integrates Pergamum Pulse without granting it assessment, adjudication, closure, risk-acceptance or certification authority;
provides conformance fixtures covering Programmes, discovery, scope, traceability, evidence, testing, automation, judgement, sampling, Findings, remediation and reporting.

Part II Foundational Principle

Regulator-grade conformance depends on assessment engineering that is as governed as the requirement set itself.

Every assessment SHALL discover the subject that actually exists, preserve its exact Baseline and Runtime state, identify its Modules and Components, resolve applicable requirements, maintain complete traceability, acquire evidence without violating tenant or white-label boundaries, and execute approved Tests against governed Oracles.

Automated validation may evaluate objective Criteria. Expert assessors may exercise bounded judgement. Sampling may support bounded inference. None of these may create missing scope, missing evidence, missing authority or universal certainty.

Findings SHALL remain visible from detection through adjudication, remediation and closure. Remediation SHALL add a new validated state without erasing the original deficiency. Assessment Packages SHALL preserve the complete decision basis without making the downstream Outcome, assurance conclusion or Certification Decision themselves.

By making assessment programme-governed, inventory-complete, traceability-driven, evidence-protected, Test-engineered, tenant-isolated, judgement-disciplined, sampling-honest, Finding-preserving and Package-verifiable, ZAYAZ can support conformance conclusions that remain reproducible, challengeable and trustworthy under regulatory scrutiny.

GitHub Repo Request for Change (RFC)

Part II — Assessment Engineering, Evidence and Test Execution​

27.13. Conformance Assessment Programmes and Portfolio Governance​

27.13.1. Assessment Programme Identity​

27.13.2. Programme Types​

27.13.3. Programme Charter​

27.13.4. Assessment Portfolio​

27.13.5. Portfolio Entry​

27.13.6. Programme Prioritisation​

27.13.7. Assessment Dependency​

27.13.8. Common-Control Assessment​

27.13.9. Assessment Reuse​

27.13.10. Reuse Limitation​

27.13.11. Programme Independence Model​

27.13.12. Programme Competence Model​

27.13.13. Programme Resource Plan​

27.13.14. Assessment Calendar​

27.13.15. Programme Risk Register​

27.13.16. Programme Stage Gates​

27.13.17. Gate Authority​

27.13.18. Programme Change Control​

27.13.19. Programme Scope Change​

27.13.20. Programme Suspension​

27.13.21. Programme Closure​

27.13.22. Programme Registry​

27.13.23. Programme Receipt​

27.13.24. Programme Validation​

27.14. Subject Discovery, Inventory and Scope Resolution​

27.14.1. Subject Discovery Plan​

27.14.2. Discovery Sources​

27.14.3. Discovery Methods​

27.14.4. Discovery Object​

27.14.5. Authoritative Inventory​

27.14.6. Inventory Classes​

27.14.7. Module Inventory​

27.14.8. Component Inventory​

27.14.9. Orphan Component​

27.14.10. Shadow Component​

27.14.11. Hidden Dependency​

27.14.12. Extension Inventory​

27.14.13. Tenant Inventory​

27.14.14. White-Label Inventory​

27.14.15. External Dependency Inventory​

27.14.16. Shared-Service Inventory​

27.14.17. Inventory Reconciliation​

27.14.18. Inventory Finding​

27.14.19. Scope Resolution Context​

27.14.20. Scope Manifest​

27.14.21. Inclusion Rule​

27.14.22. Exclusion Rule​

27.14.23. Boundary Interface​

27.14.24. Scope Completeness​

27.14.25. Subject Snapshot Assembly​

27.14.26. Snapshot Integrity​

27.14.27. Dynamic Subject Snapshot​

27.14.28. Scope Freeze​

27.14.29. Scope Change​

27.14.30. Scope Change Receipt​

27.14.31. Discovery and Scope Validation​

27.15. Requirement Traceability, Control Mapping and Coverage Analysis​

27.15.1. Conformance Traceability Matrix​

27.15.2. Traceability Directions​

27.15.3. Requirement Coverage​

27.15.4. Control Objective Coverage​

27.15.5. Control-to-Criterion Mapping​

27.15.6. Criterion-to-Test Mapping​

27.15.7. Test-to-Evidence Mapping​

27.15.8. Finding-to-Requirement Mapping​

27.15.9. One-to-Many Mapping​

27.15.10. Many-to-One Mapping​

27.15.11. Control Overlap​

27.15.12. Common-Control Mapping​

27.15.13. Shared-Responsibility Mapping​

27.15.14. Responsibility Gap​

27.15.15. Requirement Conflict​

27.15.16. Requirement Equivalence Mapping​

27.15.17. Framework Crosswalk​

27.15.18. Coverage Gap​

27.15.19. Redundant Coverage​

27.15.20. Coverage Metric​

27.15.21. Critical Requirement Override​

Part II — Assessment Engineering, Evidence and Test Execution

27.13. Conformance Assessment Programmes and Portfolio Governance

27.13.1. Assessment Programme Identity

27.13.2. Programme Types

27.13.3. Programme Charter

27.13.4. Assessment Portfolio

27.13.5. Portfolio Entry

27.13.6. Programme Prioritisation

27.13.7. Assessment Dependency

27.13.8. Common-Control Assessment

27.13.9. Assessment Reuse

27.13.10. Reuse Limitation

27.13.11. Programme Independence Model

27.13.12. Programme Competence Model

27.13.13. Programme Resource Plan

27.13.14. Assessment Calendar

27.13.15. Programme Risk Register

27.13.16. Programme Stage Gates

27.13.17. Gate Authority

27.13.18. Programme Change Control

27.13.19. Programme Scope Change

27.13.20. Programme Suspension

27.13.21. Programme Closure

27.13.22. Programme Registry

27.13.23. Programme Receipt

27.13.24. Programme Validation

27.14. Subject Discovery, Inventory and Scope Resolution

27.14.1. Subject Discovery Plan

27.14.2. Discovery Sources

27.14.3. Discovery Methods

27.14.4. Discovery Object

27.14.5. Authoritative Inventory

27.14.6. Inventory Classes

27.14.7. Module Inventory

27.14.8. Component Inventory

27.14.9. Orphan Component

27.14.10. Shadow Component

27.14.11. Hidden Dependency

27.14.12. Extension Inventory

27.14.13. Tenant Inventory

27.14.14. White-Label Inventory

27.14.15. External Dependency Inventory

27.14.16. Shared-Service Inventory

27.14.17. Inventory Reconciliation

27.14.18. Inventory Finding

27.14.19. Scope Resolution Context

27.14.20. Scope Manifest

27.14.21. Inclusion Rule

27.14.22. Exclusion Rule

27.14.23. Boundary Interface

27.14.24. Scope Completeness

27.14.25. Subject Snapshot Assembly

27.14.26. Snapshot Integrity

27.14.27. Dynamic Subject Snapshot

27.14.28. Scope Freeze

27.14.29. Scope Change

27.14.30. Scope Change Receipt

27.14.31. Discovery and Scope Validation

27.15. Requirement Traceability, Control Mapping and Coverage Analysis

27.15.1. Conformance Traceability Matrix

27.15.2. Traceability Directions

27.15.3. Requirement Coverage

27.15.4. Control Objective Coverage

27.15.5. Control-to-Criterion Mapping

27.15.6. Criterion-to-Test Mapping

27.15.7. Test-to-Evidence Mapping

27.15.8. Finding-to-Requirement Mapping

27.15.9. One-to-Many Mapping

27.15.10. Many-to-One Mapping

27.15.11. Control Overlap

27.15.12. Common-Control Mapping

27.15.13. Shared-Responsibility Mapping

27.15.14. Responsibility Gap

27.15.15. Requirement Conflict

27.15.16. Requirement Equivalence Mapping

27.15.17. Framework Crosswalk

27.15.18. Coverage Gap

27.15.19. Redundant Coverage

27.15.20. Coverage Metric

27.15.21. Critical Requirement Override