Pergamum Pulse Core 1.0 Implementation Blueprint

Version 0.1 — Complete Constitutional Runtime Foundation

1. Purpose

This Blueprint translates the governed Pergamum Pulse standards into a concrete implementation contract for Pergamum Pulse Core 1.0.

It is deliberately not an MVP specification.

The implementation decision is:

Pergamum Pulse Core 1.0 SHALL implement the complete constitutional runtime foundation required by the existing Pergamum Pulse standards. It SHALL NOT implement a reduced parallel kernel that must later be replaced.

The first implementation therefore completes the foundation for:

• stable object identity;
• independent immutable versions;
• universal lifecycle;
• bitemporal validity;
• source discovery and admission;
• source authenticity and chain of custody;
• rights and processing permissions;
• authority separation;
• scope, tenancy and security classification;
• provenance and transformation lineage;
• governed Knowledge Documents and source evidence;
• Knowledge Assertions;
• Knowledge Entities and relationships;
• mappings and crosswalks;
• review and decision records;
• change intelligence;
• Change Candidates and Change Decisions;
• deterministic projections;
• HECATE conformance;
• schema and Registry governance;
• SSSR physical-data binding;
• TrustGate evidence publication;
• regulatory temporal semantics;
• governed projection into the Methodology Rule Registry;
• historical reconstruction.

Advanced operational capabilities MAY be delivered after the Core 1.0 foundation where they are not required to prove the first vertical slice. Their object contracts SHALL nevertheless be compatible with Core 1.0 from the beginning.

---

2. Architectural Decision

Pergamum Pulse SHALL be implemented in three completion layers.

2.1. Level 1 — PP Core Complete

This Blueprint governs Level 1.

Level 1 is the complete constitutional runtime foundation and is a release requirement for Core 1.0.

2.2. Level 2 — PP Regulatory Operational Complete

Level 2 operationalises the Core for regulatory use, including source acquisition workers, PDF/HTML processing, curator workflow, regulatory monitoring, semantic difference detection, impact analysis and downstream registry projection.

The first Level 2 acceptance slice is PP-VS-001.

2.3. Level 3 — Full PP Platform Complete

Level 3 adds broad source crawling, advanced OCR, translation, large-scale semantic graph optimisation, vector retrieval, hybrid reranking, complete AI-processing governance, publication automation, rights-revocation propagation, advanced incident automation and full operational resilience.

Level 3 SHALL extend Core 1.0. It SHALL NOT require redesign of Core 1.0 identity, authority, temporal, rights, provenance or projection foundations.

---

3. Foundational Principle

The implementation shall preserve the distinction:

What the source is
        !=
What the source says
        !=
What ZAYAZ understands it to mean
        !=
What ZAYAZ has approved as governed knowledge
        !=
What ZAYAZ proposes should change
        !=
What an operational Registry contains
        !=
What Runtime executes
        !=
What TrustGate considers sufficiently trustworthy

The complete operating path is:

Authoritative or Relevant Source
          |
          v
Source Discovery / Submission
          |
          v
Source Admission
          |
          v
Source Object
          |
          v
Immutable Source Capture
          |
          +---- Rights / Authenticity / Chain of Custody
          |
          v
Knowledge Document / Document AST
          |
          v
Knowledge Section / Source Fragment
          |
          v
Knowledge Assertion
          |
          +---- Knowledge Entity / Relationship
          |
          v
Mapping / Crosswalk
          |
          v
Change Detection / Impact Analysis
          |
          v
Change Candidate
          |
          v
Change Decision
          |
          v
Projection Manifest
          |
          v
Generated Artefact
          |
          +---- HECATE Validation
          |
          v
Release / Separate Activation Authority
          |
          +---- MRR / Reference Registry / Schema / Runtime
          |
          v
TrustGate Evidence
          |
          v
ZARA Explanation / Runtime Consumer

At every material point, ZAYAZ SHALL be able to traverse this path backwards.

---

4. Normative Authority Map

This Blueprint SHALL NOT redefine the semantic authority of the existing PP corpus.

Core capability	Primary normative authority	Supporting authority	Implementation responsibility
Universal object contract	PP-KORS	PP-KDMS, PP-MPS	identity, versions, lifecycle, temporal, scope, provenance
Source acquisition	PP-KDMF-2	PP-IWCOD	discovery, admission, capture, authenticity, chain of custody
Rights	PP-RLCPS	PP-KDMF-2, PP-REAPP	rights objects, processing permissions, propagation
Knowledge document structure	PP-KDMF, PP-KDMF-2	PP-SRAG, PP-IWCOD	document, section, page/AST, fragment lineage
Assertions	PP-KAS	PP-KDMF-3, PP-KORS	typed assertion contract and evidence
Entities and relationships	PP-KORS	PP-KDMF-3	graph objects, typed edges, graph integrity
Mappings and crosswalks	PP-SMCS	PP-KAS, PP-KORS	governed semantic mapping
Change intelligence	PP-CCPS	PP-KDMF-4	difference, impact, candidate, decision, projection
Conformance	PP-HKCP	PP-KORS, PP-SRAG	deterministic rules, Findings, receipts, gates
Retrieval contract	PP-REAPP	PP-RLCPS, PP-KORS	eligibility and minimal retrieval lineage
Operational workflow	PP-IWCOD	all PP standards	cases, proposals, review-by-exception, admission
Schema governance	PP-SRAG	PP-HKCP	versioned immutable JSON Schemas
Metadata envelope	PP-MPS	PP-KDMS	deterministic metadata composition
Corpus membership	PP-DREG	PP-KDMF	register all PP normative/implementation documents
Physical signal addressability	SSSR, SSSR-REFMOD	PP-SMCS	PP-to-SSSR bridge
Trust evidence	TRUSTGATE-CONSTITUTION	PP provenance/conformance	PP-to-TrustGate evidence contract
Regulatory temporal semantics	new PP regulatory profile	PP-KORS, PP-KAS	domain-specific legal/effective time model
MRR projection	new PP-to-MRR contract	PP-CCPS, PP-SMCS	governed projection, never direct mutation

4.1. Authority hierarchy

Where implementation choices conflict with normative documents, the normative documents prevail.

The implementation SHALL preserve these distinct authority dimensions:

1. source authority;
2. legal authority;
3. evidentiary authority;
4. ZAYAZ governance authority;
5. Runtime authority.

No implementation field named authority_score, trust_score or similar may collapse these dimensions into one canonical authority value.

---

5. Core 1.0 Architectural Invariants

The following are release-blocking invariants.

PP-CORE-001 — Stable identity

Every first-class PP object has a valid registered PP identifier. Identifiers are immutable and never reused.

PP-CORE-002 — Identity is not version

An object identity and an object version are separate persisted concepts.

PP-CORE-003 — Published versions are immutable

A material change to approved meaning, applicability, authority, rights or effective behaviour creates a new object version.

PP-CORE-004 — Bitemporal state

Every material object and relationship preserves valid time and transaction time.

PP-CORE-005 — Source and capture separation

A logical Source Object is never collapsed into an acquired Source Capture.

PP-CORE-006 — Evidence before assertion

A machine-actionable Knowledge Assertion cannot become governed without resolvable Source Fragment evidence.

PP-CORE-007 — Rights before processing

Processing eligibility cannot broaden or replace canonical rights.

PP-CORE-008 — Authority is non-transitive

Graph traversal, mapping, AI processing and projection cannot increase authority.

PP-CORE-009 — Proposal is not approval

AI output, extracted values, mappings and Change Candidates remain proposals until the required governed review/decision exists.

PP-CORE-010 — Projection is not activation

A Projection Manifest or successful build cannot activate Runtime state.

PP-CORE-011 — HECATE validates; it does not decide meaning

HECATE validates objective conformance only.

PP-CORE-012 — TrustGate assesses trust; it does not determine truth

PP SHALL publish evidence to TrustGate. PP SHALL NOT import TrustGate scoring logic into knowledge truth determination.

PP-CORE-013 — PP and SSSR remain distinct

PP identities represent governed knowledge. SSSR identities represent physical data signals/addresses. A bridge connects them; neither replaces the other.

PP-CORE-014 — Registry authority pattern

Normative document -> Git-versioned machine-readable artefact -> JSON Schema -> HECATE/VW-DL validation -> immutable release -> PostgreSQL operational projection.

PP-CORE-015 — Historical reconstruction

No update may make it impossible to reconstruct what PP knew, what was valid and what was operationally projected at a requested historical time.

---

6. Core 1.0 Object Inventory

Core 1.0 SHALL implement the canonical identity and persistence contract for the following object families.

The machine-readable Object & Prefix Register remains the authority for exact prefix ownership.

6.1. Universal knowledge objects — required

Prefix	Object	Core treatment
PP-SRS-	Source Series	full persistence
PP-SRC-	Source Object	full persistence
PP-CAP-	Source Capture	full persistence
PP-RGT-	Rights Record	full persistence
PP-KD-	Knowledge Document	full persistence
PP-KS-	Knowledge Section	full persistence
PP-SF-	Source Fragment	full persistence
PP-KA-	Knowledge Assertion	full persistence
PP-KE-	Knowledge Entity	full persistence
PP-KB-	Knowledge Bundle	full persistence
PP-CIT-	Citation Object	full persistence
PP-MAP-	Mapping Object	full persistence
PP-XT-	Extraction Target	full persistence
PP-CC-	Change Candidate	full persistence
PP-CD-	Change Decision	full persistence
PP-PRJ-	Projection Manifest	full persistence
PP-HR-	Historical Record	full persistence
PP-RVW-	Review Record	full persistence
PP-FND-	Finding	full persistence
PP-INC-	Incident	core persistence; advanced operations may follow
PP-RCPT-	Conformance Receipt	full persistence

6.2. Ingest and curator operational objects — required foundation

Prefix	Object	Core treatment
PP-IC-	Ingest Case	full persistence
PP-ING-	Ingest Profile	full persistence and versioning
PP-WFI-	Workflow Instance	full persistence
PP-WFS-	Workflow Stage	full persistence
PP-WFT-	Workflow Task	full persistence
PP-PROP-	Proposal	full persistence
PP-PEV-	Proposal Evidence	full persistence
PP-RVD-	Review Decision	full persistence
PP-ASG-	Assignment	full persistence
PP-CLI-	Checklist Item	full persistence
PP-EXT-	Extraction Candidate	full persistence
PP-ECF-	Extraction Conflict	full persistence
PP-DN-	Document Node	full persistence for minimum AST
PP-CHPL-	Chunk Plan	contract and persistence
PP-CMT-	Workbench Comment	persistence; UI may follow
PP-SAP-	Stage Approval	full persistence
PP-ADM-	Admission Decision	full persistence

The first release need not include a sophisticated Workbench UI, but the workflow objects SHALL exist so operations do not have to be remodelled later.

6.3. Rights objects — required

Prefix	Object	Core treatment
PP-RGT-	Rights Record	full
PP-RGE-	Rights Evidence	full
PP-LIC-	Licence Record	full
PP-AGR-	Agreement Record	full
PP-ATR-	Attribution Record	full
PP-CIT-	Citation Object	full
PP-QTE-	Quotation Record	full
PP-PRR-	Publication Rights Record	contract + persistence
PP-RGD-	Rights Decision	full
PP-RGF-	Rights Finding	full
PP-RGI-	Rights Incident	persistence
PP-RGW-	Rights Withdrawal Record	full
PP-RGA-	Rights Audit Record	persistence

6.4. Mapping and crosswalk objects — required

Prefix	Object	Core treatment
PP-MAP-	Mapping Object	full
PP-CWS-	Crosswalk Set	full
PP-MR-	Mapping Rule	full
PP-ME-	Mapping Evidence	full
PP-MRV-	Mapping Review	full
PP-MCF-	Mapping Conflict	full
PP-MD-	Mapping Decision	full
PP-MRC-	Mapping Receipt	full
PP-MMG-	Mapping Migration	persistence

6.5. Change and projection objects — required

Prefix	Object	Core treatment
PP-CDE-	Change Detection Event	full
PP-DIF-	Difference Record	full
PP-IA-	Impact Assessment	full
PP-DA-	Dependency Assessment	full
PP-CC-	Change Candidate	full
PP-CCP-	Candidate Package	full
PP-CCF-	Candidate Conflict	full
PP-CRV-	Candidate Review	full
PP-CD-	Change Decision	full
PP-DCO-	Decision Condition	full
PP-PRJ-	Projection Manifest	full
PP-CEX-	Compiler Execution	full
PP-GA-	Generated Artefact	full
PP-VR-	Validation Receipt	full
PP-REL-	Projection Release	full
PP-AR-	Activation Request	full
PP-ACT-	Activation Record	full
PP-RBK-	Rollback Record	full
PP-PWD-	Projection Withdrawal	full
PP-CIN-	Change Incident	persistence
PP-HCR-	Historical Change Record	full

6.6. HECATE objects — required

Prefix	Object	Core treatment
PP-HCP-	HECATE Conformance Profile	full
PP-HRS-	HECATE Rule Set	full
PP-HRL-	HECATE Validation Rule	full
PP-HRQ-	HECATE Validation Request	full
PP-HES-	HECATE Evidence Snapshot	full
PP-HEP-	HECATE Execution Plan	full
PP-HEX-	HECATE Validation Execution	full
PP-FND-	Finding	full
PP-RCPT-	Conformance Receipt	full
PP-HED-	HECATE Exception Decision	full
PP-HRP-	HECATE Remediation Plan	full
PP-HAT-	HECATE Attestation	persistence
PP-HBL-	HECATE Baseline	full
PP-HHR-	HECATE Historical Record	full
PP-HIN-	HECATE Incident	persistence

6.7. Retrieval and AI-processing objects — contract complete, operational subset

Core 1.0 SHALL support persistence/contracts for the following so later retrieval infrastructure does not require a semantic redesign:

Prefix	Object	Core 1.0 operational expectation
PP-RER-	Retrieval Eligibility Record	required
PP-CHK-	Knowledge Chunk	required for first retrieval slice
PP-CHP-	Chunking Profile	required
PP-EMB-	Embedding Record	persistence contract; engine may follow
PP-EMP-	Embedding Profile	persistence contract
PP-IDX-	Retrieval Index	persistence contract
PP-IBR-	Index Build Record	persistence contract
PP-RQ-	Retrieval Request	required for governed ZARA retrieval
PP-RPL-	Retrieval Plan	required
PP-RSE-	Retrieval Session	required
PP-RRS-	Retrieval Result	required
PP-RRK-	Reranking Record	contract
PP-CTX-	Context Package	required before user-facing ZARA reasoning
PP-PRP-	Prompt Profile	contract
PP-MDP-	Model Profile	contract
PP-AIT-	AI Processing Task	contract
PP-AIR-	AI Inference Record	contract
PP-TIR-	Tool Invocation Record	contract
PP-GRD-	Grounding Record	required for user-facing explanation
PP-AEV-	AI Evaluation Record	contract
PP-RIN-	Retrieval Incident	persistence
PP-DPR-	Deletion Propagation Record	contract
PP-HPR-	Historical Processing Record	contract

Vector search, advanced reranking and model evaluation infrastructure are not Core 1.0 release blockers if the contracts above exist and the first slice can execute with governed lexical/metadata/graph retrieval.

---

7. PostgreSQL Architecture

7.1. Database namespace

All Pergamum Pulse operational persistence SHALL use the PostgreSQL schema:

pp

Existing pp.* Registry projections SHALL be preserved.

7.2. Storage design

Core 1.0 SHALL use a stable identity + immutable version + typed domain table design.

It SHALL NOT use a single unstructured JSON document store as the canonical database model.

It MAY use JSONB for extensible payloads where the governing JSON Schema remains explicit.

pp.object_identity
       |
       v
pp.object_version
       |
       +------------------+
       |                  |
       v                  v
universal envelopes    typed object tables
       |                  |
       v                  v
authority / scope      source / assertion /
provenance / time      mapping / change / etc.

7.3. Universal identity table

Recommended contract:

create table pp.object_identity (
  object_id text primary key,
  prefix text not null,
  object_type text not null,
  semantic_id text,
  canonical_name text,
  created_at timestamptz not null default now(),
  created_by text not null,
  retired_at timestamptz,
  tombstone boolean not null default false,
  unique (semantic_id, object_type)
);

Rules:

• object_id SHALL resolve against pp.object_prefix_registry;
• identifier reuse is prohibited;
• deletion of a first-class identity SHALL create/retain a tombstone;
• semantic_id uniqueness MAY be scoped by object class where the governing specification permits it.

7.4. Universal version table

create table pp.object_version (
  object_id text not null references pp.object_identity(object_id),
  version text not null,
  lifecycle_status text not null,

  valid_from timestamptz,
  valid_to timestamptz,
  recorded_at timestamptz not null default now(),
  superseded_at timestamptz,

  authority_envelope_id bigint,
  scope_envelope_id bigint,
  applicability_envelope_id bigint,
  provenance_root_id bigint,

  security_classification text,
  content_digest text not null,
  schema_uri text not null,
  schema_digest text,

  immutable boolean not null default true,
  primary key (object_id, version)
);

Object-version validity denotes the domain-valid interval of that particular governed PP representation. valid_from / valid_to SHALL NOT, by themselves, be interpreted as legal adoption, publication, entry into force, legal or reporting-period applicability, repeal, Runtime activation or Runtime deactivation.

recorded_at / superseded_at are PP transaction/system time. They answer when Pergamum Pulse recorded the exact version and when it ceased to be the transaction-current PP version. They SHALL NOT be interpreted as legal-event time or regulatory applicability time.

The implementation SHALL preserve the distinction:

PP object-version valid time
        !=
PP transaction/system time
        !=
scope/applicability-envelope valid time
        !=
regulatory legal-event time
        !=
regulatory/reporting-period applicability

The implementation SHALL not depend on a mutable is_current flag as the source of historical truth. A materialized/current view MAY be provided for performance.

7.5. Universal supporting tables

Core 1.0 SHALL include at least:

pp.object_alias
pp.external_identifier
pp.lifecycle_transition
pp.authority_envelope
pp.authority_dimension
pp.scope_envelope
pp.applicability_envelope
pp.provenance_record
pp.transformation_record
pp.actor_reference
pp.review_reference
pp.object_classification
pp.object_owner
pp.object_digest
pp.object_dependency
pp.relationship_identity
pp.relationship_version
pp.relationship_evidence

pp.ingest_case
pp.ingest_profile
pp.workflow_instance
pp.workflow_stage
pp.workflow_task

pp.proposal
pp.proposal_evidence
pp.review_decision

pp.assignment
pp.checklist_item
pp.chunk_plan
pp.workbench_comment
pp.stage_approval

pp.review_record
pp.historical_record
pp.incident
pp.extraction_target
pp.rights_incident

pp.regulatory_temporal_profile
pp.regulatory_applicability_period

7.6. Relationship persistence

Relationships SHALL be typed, versioned and bitemporal.

At minimum:

create table pp.relationship_version (
  relationship_id text not null,
  version text not null,
  relationship_type text not null,
  source_object_id text not null,
  source_object_version text not null,
  target_object_id text not null,
  target_object_version text not null,
  direction text not null,
  valid_from timestamptz,
  valid_to timestamptz,
  recorded_at timestamptz not null default now(),
  superseded_at timestamptz,
  authority_envelope_id bigint,
  scope_envelope_id bigint,
  provenance_root_id bigint,
  primary key (relationship_id, version)
);

Relationship-type constraints SHALL resolve from the governed Relationship Type Registry.

7.7. Source and capture tables

Core 1.0 SHALL provide typed tables including:

pp.source_series
pp.source_object
pp.source_candidate
pp.source_admission_request
pp.source_admission_decision
pp.source_capture
pp.source_capture_blob
pp.source_authenticity_assessment
pp.capture_chain_of_custody
pp.source_locator
pp.source_page
pp.page_representation
pp.document_node
pp.extraction_candidate
pp.extraction_conflict

Captured bytes SHALL be stored in governed object storage, not directly in ordinary relational columns except where a specific small-artifact policy permits it.

pp.source_capture SHALL preserve the immutable digest, exact storage object identity, acquisition method, acquisition time and acquiring actor.

7.7.1. Early Source Admission persistence

PP-KDMF-2 Source Admission and PP-IWCOD final Knowledge Admission are distinct governance decisions.

Core 1.0 SHALL persist early source-intake governance using:

pp.source_candidate
pp.source_admission_request
pp.source_admission_decision

These are operational governance records. They SHALL NOT consume PP-ADM-, because PP-ADM- is normatively reserved by PP-IWCOD for final Knowledge Admission.

A Source Candidate, Source Admission Request or early Source Admission Decision SHALL NOT directly create a row in pp.object_identity, pp.object_version or pp.source_object. An authorising early Source Admission Decision may permit preparation of a canonical source-object.json; canonical persistence SHALL still occur through the Governed Object Loader.

For legacy reconciliation, proposed_source_object_id MAY contain a historically allocated PP-SRC identity where evidence proves that identity is the one under review. The workflow SHALL preserve that identity and SHALL NOT mint a replacement merely because canonical PostgreSQL registration is missing.

Source Admission workflow transaction/system timestamps SHALL NOT be interpreted as legal publication, entry into force, applicability or reporting-period time.

7.8. Rights tables

Core 1.0 SHALL implement:

pp.rights_record
pp.rights_evidence
pp.licence_record
pp.agreement_record
pp.attribution_record
pp.quotation_record
pp.publication_rights_record
pp.rights_decision
pp.rights_finding
pp.rights_withdrawal
pp.rights_audit

The existing projections remain:

pp.rights_processing_operation_registry
pp.rights_permission_state_registry

Rights evaluation SHALL always preserve the canonical PP-RGT- object and shall not treat Registry lookup output as a rights grant.

7.9. Knowledge and semantic tables

pp.knowledge_document
pp.knowledge_section
pp.source_fragment
pp.knowledge_assertion
pp.assertion_subject
pp.assertion_predicate
pp.assertion_object
pp.assertion_evidence
pp.assertion_qualifier
pp.assertion_exception
pp.assertion_condition
pp.assertion_conflict
pp.knowledge_entity
pp.entity_property
pp.knowledge_bundle
pp.bundle_member
pp.citation_object

The assertion table SHALL store typed subject/predicate/object references. canonical_statement is human-readable support, not the machine semantic model.

7.10. Mapping tables

pp.mapping_object
pp.crosswalk_set
pp.crosswalk_member
pp.mapping_rule
pp.mapping_evidence
pp.mapping_review
pp.mapping_conflict
pp.mapping_decision
pp.mapping_receipt
pp.mapping_migration

Every approved mapping SHALL pin source and target object versions unless an explicitly governed Mapping Rule permits version ranges.

7.11. Change and projection tables

pp.change_detection_event
pp.difference_record
pp.impact_assessment
pp.dependency_assessment
pp.change_candidate
pp.candidate_package
pp.candidate_package_member
pp.candidate_conflict
pp.candidate_review
pp.change_decision
pp.decision_condition
pp.projection_manifest
pp.compiler_execution
pp.generated_artefact
pp.validation_receipt
pp.projection_release
pp.activation_request
pp.activation_record
pp.rollback_record
pp.projection_withdrawal
pp.change_incident
pp.historical_change_record

7.12. HECATE tables

pp.hecate_conformance_profile
pp.hecate_rule_set
pp.hecate_rule
pp.hecate_rule_set_member
pp.hecate_validation_request
pp.hecate_evidence_snapshot
pp.hecate_evidence_snapshot_member
pp.hecate_execution_plan
pp.hecate_validation_execution
pp.finding
pp.conformance_receipt
pp.hecate_exception_decision
pp.hecate_remediation_plan
pp.hecate_attestation
pp.hecate_baseline
pp.hecate_historical_record
pp.hecate_incident

7.13. Retrieval-contract tables

Core 1.0 SHALL include at least:

pp.retrieval_eligibility
pp.chunking_profile
pp.knowledge_chunk
pp.retrieval_request
pp.retrieval_plan
pp.retrieval_session
pp.retrieval_result
pp.context_package
pp.grounding_record

Additional REAPP tables MAY be introduced in the same schema family without changing the universal object model.

7.14. Transactional outbox

Core 1.0 SHALL include:

pp.event_outbox

and emitted through pp.event_outbox using the TrustGate evidence-event schema:

pp.source.admitted
pp.capture.created
pp.assertion.reviewed

All externally published material PP events SHALL be inserted transactionally with the state change they describe.

This prevents a committed PP decision from existing without its required downstream event, and prevents event publication from creating state that was not committed.

---

8. Governed Registry Architecture

8.1. Existing Registry assets to retain

The following already exist and SHALL be reused:

config/system/pergamum-pulse/object-prefix-register.json
config/system/pergamum-pulse/document-register.json
config/system/pergamum-pulse/lifecycle-registry.json
config/system/pergamum-pulse/rights-vocabulary.json

Their PostgreSQL counterparts remain operational projections.

8.2. Core 1.0 Registry additions

Core 1.0 SHOULD add machine-readable governed Registries for:

relationship-type-registry.json
assertion-type-registry.json
predicate-registry.json
normative-force-registry.json
authority-class-registry.json
source-type-registry.json
source-admission-outcome-registry.json
authenticity-state-registry.json
security-classification-registry.json
knowledge-scope-registry.json
review-type-registry.json
review-outcome-registry.json
mapping-type-registry.json
mapping-direction-registry.json
mapping-cardinality-registry.json
change-class-registry.json
change-decision-outcome-registry.json
projection-target-type-registry.json
hecate-severity-registry.json
hecate-gate-outcome-registry.json
regulatory-temporal-event-type-registry.json
trustgate-evidence-event-type-registry.json

A Registry SHALL NOT be invented merely because a field has an enum. Registry treatment is appropriate where the vocabulary has cross-object semantic meaning, governance impact or runtime reuse.

8.3. Registry authority flow

Normative PP document
      |
      v
Git-versioned JSON Registry
      |
      v
Registry JSON Schema
      |
      v
VW-DL / HECATE validation
      |
      v
Immutable release
      |
      v
PostgreSQL projection
      |
      v
Runtime lookup

Runtime code SHALL not hard-code governed vocabulary values where a canonical Registry exists.

---

9. JSON Schema Package

9.1. Namespace

Core 1.0 schemas SHALL use explicit versioned URIs under:

https://schemas.zayaz.io/pergamum-pulse/core/1.0.0/

No normative reference may use /latest/ or /current/.

9.2. Recommended repository structure

schemas/pergamum-pulse/core/1.0.0/
├── common/
│   ├── object-identity.schema.json
│   ├── object-version.schema.json
│   ├── temporal.schema.json
│   ├── authority.schema.json
│   ├── scope.schema.json
│   ├── applicability.schema.json
│   ├── provenance.schema.json
│   ├── actor-reference.schema.json
│   ├── digest.schema.json
│   └── relationship.schema.json
├── source/
│   ├── source-series.schema.json
│   ├── source-object.schema.json
│   ├── source-candidate.schema.json
│   ├── source-capture.schema.json
│   ├── source-authenticity.schema.json
│   ├── source-locator.schema.json
│   └── chain-of-custody.schema.json
├── rights/
│   ├── rights-record.schema.json
│   ├── rights-evidence.schema.json
│   ├── licence-record.schema.json
│   ├── agreement-record.schema.json
│   ├── attribution-record.schema.json
│   ├── rights-decision.schema.json
│   └── rights-withdrawal.schema.json
├── knowledge/
│   ├── knowledge-document.schema.json
│   ├── knowledge-section.schema.json
│   ├── source-fragment.schema.json
│   ├── knowledge-assertion.schema.json
│   ├── knowledge-entity.schema.json
│   ├── knowledge-bundle.schema.json
│   └── citation-object.schema.json
├── mapping/
│   ├── mapping-object.schema.json
│   ├── crosswalk-set.schema.json
│   ├── mapping-rule.schema.json
│   ├── mapping-evidence.schema.json
│   └── mapping-decision.schema.json
├── change/
│   ├── change-detection-event.schema.json
│   ├── difference-record.schema.json
│   ├── impact-assessment.schema.json
│   ├── change-candidate.schema.json
│   ├── change-decision.schema.json
│   ├── projection-manifest.schema.json
│   ├── generated-artefact.schema.json
│   └── activation-record.schema.json
├── hecate/
│   ├── conformance-profile.schema.json
│   ├── rule-set.schema.json
│   ├── validation-rule.schema.json
│   ├── validation-request.schema.json
│   ├── evidence-snapshot.schema.json
│   ├── finding.schema.json
│   └── conformance-receipt.schema.json
├── retrieval/
│   ├── retrieval-eligibility.schema.json
│   ├── chunking-profile.schema.json
│   ├── knowledge-chunk.schema.json
│   ├── retrieval-request.schema.json
│   ├── retrieval-plan.schema.json
│   ├── context-package.schema.json
│   └── grounding-record.schema.json
├── regulatory/
│   ├── regulatory-temporal-profile.schema.json
│   └── regulatory-temporal-event.schema.json
├── integration/
│   ├── sssr-binding.schema.json
│   ├── trustgate-evidence-event.schema.json
│   └── mrr-projection-package.schema.json
└── fixtures/
    └── pp-vs-001/

9.3. Schema release package

Each Core schema release SHALL generate:

manifest.json
catalog.json
checksums.sha256
dependency-graph.json
deprecations.json

The release SHALL record the Git commit, release timestamp, HECATE/VW-DL receipt and schema digest.

---

10. HECATE Core 1.0 Conformance

10.1. HECATE execution model

Core 1.0 SHALL implement the generic HKCP execution architecture rather than a set of ad hoc validators.

Validation Request
      |
      v
Evidence Snapshot
      |
      v
Conformance Profile
      |
      v
Rule Sets / Rules
      |
      v
Execution Plan
      |
      v
Validation Execution
      |
      v
Findings
      |
      v
Gate Evaluation
      |
      v
Conformance Receipt

10.2. Initial Core Rule families

The first baseline SHALL contain rules for:

Identity and Registry

• valid PP prefix;
• registered object class;
• identifier non-reuse;
• semantic identity constraints;
• version syntax;
• schema URI/digest presence.

Lifecycle

• registered lifecycle state;
• permitted object-specific lifecycle state;
• transition provenance;
• tombstone retention.

Temporal

• bitemporal field completeness;
• valid interval logic;
• overlapping incompatible validity detection;
• historical version consistency;
• regulatory temporal-event consistency.

Authority

• all required authority dimensions represented;
• no illegal authority propagation;
• decision authority present where required.

Rights

• Rights Record resolution;
• processing-right completeness;
• rights validity period;
• required attribution;
• derived-object rights inheritance;
• retrieval eligibility cannot broaden rights.

Source and provenance

• source/capture separation;
• capture digest present;
• storage reference present;
• chain-of-custody completeness;
• transformation lineage complete;
• actor and timestamp present.

Knowledge

• Source Fragment locator resolves;
• assertion evidence resolves;
• assertion predicate registered;
• assertion subject/object types valid;
• normative force registered;
• applicability complete where required.

Graph and mapping

• relationship type registered;
• source/target class constraints;
• direction/cardinality constraints;
• mapping source and target versions pinned;
• no dangling relationships;
• no unauthorised cross-tenant edge.

Change and projection

• Candidate links to source knowledge;
• Decision links to Candidate;
• Decision authority and conditions valid;
• projection only consumes eligible Decisions;
• compiler version pinned;
• generated artefact digest present;
• projection and activation distinct.

Integration

• SSSR binding resolves;
• TrustGate evidence envelope is replayable and digest-bound;
• MRR projection package pins PP lineage.

10.3. Initial Core gates

Core 1.0 SHALL define at least:

PP-HCP-SOURCE-ADMISSION
PP-HCP-KNOWLEDGE-ADMISSION
PP-HCP-ASSERTION-ADMISSION
PP-HCP-MAPPING-ADMISSION
PP-HCP-PROJECTION-ELIGIBILITY
PP-HCP-MRR-RELEASE-READINESS
PP-HCP-RETRIEVAL-ELIGIBILITY
PP-HCP-HISTORICAL-REPLAY

These are semantic names for governed HECATE Profiles; final PP identifiers SHALL be minted through the Object & Prefix Register rules.

10.4. What HECATE cannot do

A passing receipt SHALL NOT:

• decide the legal meaning of a provision;
• approve an assertion merely because its structure is valid;
• approve a mapping based on similarity;
• approve a Change Candidate;
• issue a Change Decision;
• grant rights;
• create Runtime authority;
• create TrustGate trust.

---

11. Addition A — Regulatory Temporal Profile

11.1. Purpose

The universal KORS temporal contract is necessary but not sufficient for legislation, regulation and regulatory standards.

Core 1.0 SHALL therefore add a Regulatory Temporal Profile layered on the universal bitemporal model.

This is a domain profile, not a replacement for PP-KORS temporal fields, pp.object_version, or pp.applicability_envelope.

The temporal layers SHALL remain distinct:

pp.object_version.valid_from / valid_to
    = domain-valid interval of the exact governed PP object version

pp.object_version.recorded_at / superseded_at
    = PP transaction/system time

pp.applicability_envelope.valid_from / valid_to
    = validity interval of the evidence-bounded scope/applicability envelope

pp.regulatory_temporal_profile
    = legal/regulatory event time and governed legal status

pp.regulatory_applicability_period
    = reporting-period or other period-basis application regime

No generic PP field SHALL silently be reinterpreted as legal entry into force or reporting-period applicability.

11.2. Required temporal concepts

The Profile SHALL support common legal-event facts including, where applicable:

adopted_at
signed_at
published_at
entered_into_force_at
transposition_deadline
repealed_at
ceased_to_be_in_force_at

It SHALL also allow jurisdiction-specific governed event types without adding universal columns for every legal system.

Early, mandatory, optional, transitional, derogated, suspended or analogous application regimes SHALL be represented as regulatory applicability periods rather than collapsed into legal-event timestamps.

11.3. Regulatory temporal profile persistence

Core 1.0 SHALL provide:

pp.regulatory_temporal_profile

Recommended contract:

create table pp.regulatory_temporal_profile (
  object_id text not null,
  version text not null,
  legal_status text not null,

  adopted_at timestamptz,
  signed_at timestamptz,
  published_at timestamptz,
  entered_into_force_at timestamptz,
  transposition_deadline timestamptz,
  repealed_at timestamptz,
  ceased_to_be_in_force_at timestamptz,

  additional_events jsonb not null default '[]'::jsonb,
  evidence_refs jsonb not null default '[]'::jsonb,
  basis_assertion_ids jsonb not null default '[]'::jsonb,

  notes text,
  recorded_at timestamptz not null default now(),
  created_by text not null,
  profile_digest text,

  primary key (object_id, version),
  foreign key (object_id, version)
    references pp.object_version(object_id, version)
);

legal_status SHALL be governed independently of the timestamp columns. A status such as in_force SHALL NOT be inferred merely because entered_into_force_at is non-null; the applicable legal evidence and governance decision remain authoritative.

additional_events preserves jurisdiction-specific legal-event facts together with their precision, jurisdiction and evidence/provenance under the governing schema/profile.

The profile is immutable for an exact PP object version. A material change to governed legal status or temporal meaning creates a new PP object version rather than updating the existing profile.

11.4. Regulatory/reporting applicability periods

Core 1.0 SHALL provide:

pp.regulatory_applicability_period

One regulatory temporal profile MAY have zero-to-many applicability-period rows.

Recommended contract:

create table pp.regulatory_applicability_period (
  object_id text not null,
  version text not null,
  ordinal integer not null,

  applicability_type text not null,
  period_basis text not null,
  period_from date,
  period_to date,
  period_from_inclusive boolean not null default true,
  period_to_inclusive boolean not null default true,

  applicability_envelope_id bigint,
  conditions jsonb not null default '[]'::jsonb,
  evidence_refs jsonb not null default '[]'::jsonb,
  basis_assertion_ids jsonb not null default '[]'::jsonb,

  notes text,
  recorded_at timestamptz not null default now(),
  created_by text not null,
  period_digest text,

  primary key (object_id, version, ordinal),
  foreign key (object_id, version)
    references pp.regulatory_temporal_profile(object_id, version),
  foreign key (applicability_envelope_id)
    references pp.applicability_envelope(applicability_envelope_id)
);

applicability_type SHALL support governed values such as mandatory, optional, transitional, derogated, suspended and not_applicable without hard-coding those values into universal persistence.

period_basis SHALL state how the date boundaries are interpreted, for example:

calendar_date
financial_year_beginning
financial_year_ending
reporting_period_beginning
reporting_period_ending

This is required because a rule such as:

applies for financial years beginning on or after 1 January 2027

is not equivalent to:

enters into legal force on 1 January 2027.

The optional applicability_envelope_id identifies who/where/what is in scope for that exact period. Period-specific elections, qualifications, exceptions and transitional conditions belong in conditions with resolvable evidence and governed basis assertions.

11.5. Regulatory query semantics

PP SHALL distinguish questions such as:

Was this source adopted by date X?
Was this source published by date X?
Was it legally in force on date X?
Was it applicable to this organisation/jurisdiction?
Was it applicable to the reporting period?
Was early or optional application permitted?
Was mandatory application required?
Which transitional conditions applied?
What did ZAYAZ know on PP transaction date Y?

These questions SHALL NOT be answered from a single generic effective_date, valid_from, recorded_at or bridge timestamp.

11.6. PP ↔ SSSR temporal boundary

The Regulatory Temporal Profile remains PP regulatory-knowledge state. SSSR provides physical signal/address resolution and SHALL NOT infer legal applicability.

PP-SSSR-010 continues to validate temporal/lifecycle coherence of the PP↔SSSR binding projection itself. Legal-event and reporting-period applicability SHALL be resolved in PP before an applicability-dependent mapping, projection or Runtime release is activated.

The regulatory temporal tables and material columns SHALL be registered in SSSR where they are intentionally discoverable/addressable as physical ZAYAZ signals, under the existing PP-to-SSSR registration rule. Such registration creates physical addressability only and does not transfer regulatory-semantic authority from PP to SSSR.

---

12. Addition B — PP to MRR Projection Contract

12.1. Architectural rule

The Methodology Rule Registry is an operational Registry.

It SHALL NOT become an independent source of regulatory or methodological truth.

The canonical chain is:

PP Knowledge Assertion
       |
       v
PP Mapping / Extraction Target
       |
       v
Change Candidate
       |
       v
Change Decision
       |
       v
Projection Manifest
       |
       v
Generated MRR Projection Package
       |
       v
HECATE MRR Release Gate
       |
       v
MRR release / separate activation authority

12.2. Projection package

Core 1.0 SHALL define mrr-projection-package.schema.json.

Minimum contract:

mrr_projection_package:
  projection_manifest_id: PP-PRJ-...
  generated_artefact_id: PP-GA-...

  target:
    registry: methodology_rule_registry
    rule_semantic_id: mrr.scope2.electricity.factor-selection

  lineage:
    assertions:
      - object_id: PP-KA-...
        version: 1.0.0
    mappings:
      - object_id: PP-MAP-...
        version: 1.0.0
    change_candidate: PP-CC-...
    change_decision: PP-CD-...

  rule:
    rule_type: selection
    applicability: {}
    conditions: []
    exceptions: []
    inputs: []
    outputs: []
    selection_logic: {}
    explanation: {}

  temporal: {}
  authority: {}
  provenance: {}
  digest: sha256:...

12.3. Activation boundary

PP MAY produce and validate the MRR projection package.

PP SHALL NOT silently insert an active MRR rule unless the MRR activation authority explicitly accepts the release.

The activated MRR rule SHALL retain:

PP-PRJ projection manifest
PP-GA generated artefact
PP-CD change decision
PP-KA source assertions
PP-SF source evidence

as immutable lineage references.

12.4. Auditor correction

Where an auditor later corrects an MRR-derived decision, the correction SHALL be classified against the causal layer:

source interpretation
assertion
mapping
MRR rule
factor Registry record
resolver ranking
source activity data
connector mapping
calculation
professional judgement

A correction SHALL NOT automatically rewrite PP knowledge.

It SHALL create evidence, review and where appropriate a Change Candidate against the correct layer.

---

13. Addition C — PP to SSSR Bridge

13.1. Separation of concerns

Pergamum Pulse and SSSR answer different questions.

PP:
What governed knowledge object or assertion is this?

SSSR:
Where does this physical field/signal live and how is it addressed?

They SHALL not be merged.

13.2. Semantic mapping

The semantic relationship between a PP object/property and an SSSR signal SHALL be represented through governed PP mapping semantics where material.

Example:

PP-KA / PP-KE semantic property
        |
        v
PP-MAP operationalises / represented_by / maps_to
        |
        v
SSSR signal identity / CMID / canonical SSSR reference

13.3. Operational projection

Core 1.0 SHALL maintain an operational bridge projection:

pp.sssr_binding_projection

Recommended fields:

binding_id
mapping_id
pp_object_id
pp_object_version
pp_property_path
sssr_signal_id
cmid
sssr_reference_json
row_resolution_mode
scope_resolution_mode
valid_from
valid_to
recorded_at
superseded_at
status
provenance_digest

sssr_reference_json SHALL conform to the SSSR Canonical Reference Model.

13.4. Row identity

A PP-to-SSSR binding identifies the physical field definition.

It SHALL NOT hard-code a tenant/client row identity into the semantic mapping.

Runtime row resolution SHALL use the SSSR reference dimensions, including row_id or scoped identity such as the E-C-O Number where applicable.

Therefore:

semantic evidence type
      |
      v
PP -> SSSR field binding
      |
      v
runtime scope / E-C-O Number resolution
      |
      v
physical row + field

This preserves template and knowledge reuse across tens of thousands of tenants.

13.5. SSSR registration of PP itself

Every production pp table and material field SHALL be registered in SSSR where it is intended to be discoverable/addressable as a ZAYAZ signal.

This creates the reverse path:

PP semantic object
<------------------------>
SSSR physical address

without making either system authoritative for the other's domain.

13.6. Regulatory temporal semantics

Regulatory legal-event time and reporting-period applicability remain upstream PP knowledge. pp.sssr_binding_projection.valid_from / valid_to describe the validity of the semantic-to-physical bridge binding; they SHALL NOT be treated as legal entry-into-force or regulatory applicability fields.

Where a PP mapping or projection is applicable only under a particular regulatory temporal regime, PP SHALL resolve the governing object version and pp.regulatory_applicability_period before projection/activation. SSSR resolves the physical signal after that governed PP decision; it does not choose the applicable legal regime.

---

14. Addition D — PP to TrustGate Evidence Contract

14.1. Constitutional boundary

TrustGate answers:

Can this information be trusted sufficiently for its intended purpose?

Pergamum Pulse answers:

What governed knowledge, evidence, interpretation, decision and lineage exists?

PP SHALL provide evidence to TrustGate. TrustGate SHALL not become the source of PP truth.

14.2. Canonical PP evidence events

Core 1.0 SHOULD define governed event types including:

pp.source.admitted
pp.capture.created
pp.capture.authenticity_assessed
pp.rights.decision_recorded
pp.knowledge.admitted
pp.assertion.reviewed
pp.assertion.superseded
pp.mapping.decision_recorded
pp.change_candidate.created
pp.change_decision.recorded
pp.projection.generated
pp.hecate.receipt.issued
pp.projection.released
pp.activation.observed
pp.object.quarantined
pp.object.withdrawn

14.3. Evidence event envelope

Core 1.0 SHALL define trustgate-evidence-event.schema.json.

Minimum payload:

pp_trustgate_evidence_event:
  event_id: uuid
  event_type: pp.hecate.receipt.issued
  event_version: 1.0.0
  occurred_at: 2026-08-22T00:00:00Z

  subject:
    object_id: PP-KA-...
    object_version: 1.0.0

  intended_purpose: regulatory_reasoning

  evidence:
    source_objects: []
    source_fragments: []
    review_records: []
    hecate_receipts: []

  lineage:
    projection_manifest_id: null
    generated_artefact_id: null

  digests:
    subject_digest: sha256:...
    evidence_digest: sha256:...

  actor: {}
  provenance: {}

14.4. No PP trust score

The PP evidence envelope SHALL NOT assign a TrustGate trust score.

TrustGate consumes the evidence, resolves the applicable TrustGate policy and produces its own governed trust decision.

14.5. Delivery

Events SHALL originate from pp.event_outbox and be delivered through the approved ZAYAZ event transport/CMCB infrastructure.

Delivery SHALL be idempotent.

The PP event identifier or deterministic idempotency key SHALL be preserved into existing TrustGate telemetry where an adapter is required.

---

15. Source Acquisition and Admission

15.1. Initial acquisition profiles

Core 1.0 SHALL support configuration for the IWCOD initial profiles, but the first implemented executable profiles SHOULD be:

regulatory-final
regulatory-draft
licensed-standard
Viroway-internal

The first acceptance slice requires regulatory-final.

15.2. Deterministic intake sequence

submission
  -> malware/security check
  -> MIME/type detection
  -> byte digest
  -> duplicate analysis
  -> source candidate
  -> source identity proposal
  -> authority/authenticity review
  -> rights review
  -> admission decision
  -> immutable object storage
  -> Source Capture
  -> technical extraction
  -> AST candidate

15.3. Source authenticity

Authenticity SHALL remain separate from source authority.

A source may be authentic but non-authoritative for the purpose in question.

An authenticity assessment SHOULD preserve:

source location
publisher/issuer identity
transport/security evidence
file digest
signature evidence where present
official-portal comparison
version/edition match
assessment method
assessor
confidence
review requirement
provenance

15.4. Immutable capture

The source bytes SHALL remain immutable.

OCR, Markdown conversion, normalisation, translation and AI extraction SHALL be separate governed transformations.

11.5. Governed persistence sidecar and loader boundary

The regulatory temporal profile is an exact-version extension, not an independent first-class PP object. It SHALL therefore not receive a separate PP object identity merely to persist temporal metadata.

The repository contract SHALL provide a schema-validated sidecar:

regulatory-temporal-sidecar.schema.json

The sidecar SHALL bind to exactly one existing or transaction-planned pp.object_version and SHALL contain the regulatory temporal profile plus zero-to-many regulatory applicability periods. Its persistence SHALL use the Pergamum Pulse Governed Object Loader and the same verified database/TLS guard, SERIALIZABLE transaction discipline, idempotency checks and fail-closed reference validation as canonical PP object loading.

The sidecar SHALL NOT modify the governing JSON Schema of the target PP object. This preserves the immutability of released Core object schemas and keeps the following concepts distinct:

PP object payload/schema
        !=
regulatory temporal extension
        !=
PP transaction/system time
        !=
Runtime activation state

The persistence adapter SHALL:

1. validate legal_status, applicability_type and period_basis against governed registries;
2. require the exact target object_id + version to exist, or be the exact object version being loaded in the same transaction;
3. validate version-pinned evidence references and resolvable basis assertion identities;
4. create period-specific pp.applicability_envelope rows only from explicit sidecar applicability payloads;
5. persist pp.regulatory_temporal_profile and pp.regulatory_applicability_period atomically;
6. record non-authority-bearing verification digests for the sidecar and its canonical JSON representation;
7. reconstruct and compare existing persistence on rerun rather than silently overwrite or repair it; and
8. treat any conflicting existing immutable row as a governed repair condition.

The adapter validates persistence conformance only. It SHALL NOT infer legal dates, decide legal status, determine whether optional application should be elected, create legal authority, or activate an SSSR/Runtime binding.

---

16. Document and Evidence Model

16.1. Canonical machine representation

Core 1.0 SHALL use a governed document AST as the canonical machine representation for ingested document structure.

MDX is a useful publication/view representation. It SHALL NOT silently replace the source capture or the AST as source evidence.

16.2. Physical and semantic evidence

The implementation SHALL preserve:

Source Capture
   |
   v
Document Page / Page Representation
   |
   v
Document AST / Document Node
   |
   v
Knowledge Section
   |
   v
Source Fragment
   |
   v
Knowledge Assertion

A page is a physical evidence boundary.

A Source Fragment is a semantic evidence boundary.

A retrieval chunk is a derived processing boundary.

These SHALL remain separate.

16.3. Source locator

A Source Fragment locator SHALL support source-appropriate coordinates, including:

page
article
clause
paragraph
section
annex
table
row
cell
figure
dataset record
API field
timestamped media segment
character offsets
bounding boxes

The locator SHALL be reproducible against the pinned Source Capture where technically possible.

---

17. Knowledge Assertion Implementation

17.1. Required persisted semantics

A machine-actionable Knowledge Assertion SHALL preserve:

identity
version
type
canonical statement
subject
predicate
object
source evidence
normative force
authority
rights
applicability
confidence
temporal validity
review state
status
provenance

17.2. Predicate governance

Predicates SHALL resolve from a governed Predicate Registry.

Runtime code SHALL not treat arbitrary free-text verbs as canonical predicates.

17.3. Normative force

The governed normative-force vocabulary SHALL distinguish at least concepts defined by KAS, such as legally required, regulator required, standards SHALL, SHOULD, MAY, prohibited, permitted, recommended, informative, descriptive, evidentiary, inferred and unresolved.

17.4. AI-assisted assertions

An AI-assisted assertion SHALL preserve:

proposal identity
model/profile identity
prompt profile
retrieval/context lineage
evidence
confidence
reasoning summary suitable for review
known limitations
review requirement

AI-generated assertion proposals SHALL not become approved through model confidence alone.

---

18. Graph and Mapping Implementation

18.1. Database choice

Core 1.0 SHALL NOT require a separate graph database.

The canonical graph can be persisted in PostgreSQL using typed relationship tables and appropriate indexes.

A graph database MAY later be introduced as a projection for specialised traversal performance.

It SHALL not become a second semantic authority.

18.2. Explainable traversal

Every material traversal result SHOULD expose:

start object
relationship path
object versions
valid time
transaction time
scope filters
authority filters
rights filters
result path

18.3. Mapping non-authority

Similarity MAY propose a Mapping Object.

Similarity SHALL NOT approve equivalence.

Approved mappings SHALL retain evidence, rationale, authority, applicability, confidence, review and temporal validity.

---

19. Change Intelligence and Projection

19.1. Required chain

A material source/knowledge change that may affect ZAYAZ execution SHALL use:

Change Detection Event
      -> Difference Record
      -> Impact Assessment
      -> Dependency Assessment
      -> Change Candidate
      -> Candidate Review
      -> Change Decision
      -> Projection Eligibility
      -> Projection Manifest
      -> Compiler Execution
      -> Generated Artefact
      -> Validation Receipt
      -> Projection Release
      -> Activation Request
      -> Separate Activation Record

19.2. Deterministic projection

A Projection Manifest SHALL pin:

all source object IDs and versions
all approved Change Decisions
compiler/generator identity and version
configuration versions
schema versions
Registry versions
input digests
output digests
HECATE receipts

Two executions with identical pinned inputs SHALL either produce identical output digests or generate a blocking reproducibility Finding.

19.3. Rollback

Every production activation resulting from a PP projection SHALL identify a rollback target or explicitly record why rollback is not technically possible and what compensating recovery path exists.

---

20. Retrieval and ZARA Boundary

20.1. Early ZARA role

ZARA MAY participate during ingest as a proposal generator for:

source identity
source classification
authority classification
structure
assertions
entities
mappings
semantic differences
Change Candidates

These outputs remain proposals.

20.2. User-facing ZARA role

User-facing regulatory reasoning SHALL use governed PP retrieval.

The retrieval path SHALL preserve:

Retrieval Request
      -> Retrieval Plan
      -> eligible knowledge only
      -> authority/rights/time/scope filters
      -> Retrieval Session
      -> Retrieval Results
      -> Context Package
      -> inference/tool record where applicable
      -> Grounding Record

20.3. Core 1.0 retrieval implementation

The first release MAY use:

PostgreSQL full-text search
metadata filters
typed relationship traversal
exact object lookup
exact fragment/citation lookup

before advanced vector infrastructure exists.

The semantic contract SHALL already support later hybrid retrieval.

---

21. API Contracts

Core 1.0 SHOULD expose versioned service contracts under:

/pp/v1/

Suggested bounded APIs:

21.1. Object API

GET  /pp/v1/objects/{object_id}
GET  /pp/v1/objects/{object_id}/versions
GET  /pp/v1/objects/{object_id}/lineage
GET  /pp/v1/objects/{object_id}/relationships
GET  /pp/v1/history/{object_id}

Historical reads SHALL support both valid-time and transaction-time parameters.

21.2. Ingest API

POST /pp/v1/ingest/cases
POST /pp/v1/ingest/captures
POST /pp/v1/ingest/proposals
POST /pp/v1/ingest/reviews
POST /pp/v1/ingest/admissions

21.3. Knowledge API

GET  /pp/v1/assertions
GET  /pp/v1/assertions/{id}
POST /pp/v1/assertions/proposals
POST /pp/v1/assertions/{id}/reviews
GET  /pp/v1/entities/{id}
GET  /pp/v1/fragments/{id}

21.4. Mapping API

POST /pp/v1/mappings/proposals
POST /pp/v1/mappings/{id}/reviews
GET  /pp/v1/crosswalks/{id}

21.5. Change/projection API

POST /pp/v1/changes/detect
POST /pp/v1/change-candidates
POST /pp/v1/change-decisions
POST /pp/v1/projections
GET  /pp/v1/projections/{id}
POST /pp/v1/projections/{id}/release

21.6. HECATE API

POST /pp/v1/hecate/validate
GET  /pp/v1/hecate/executions/{id}
GET  /pp/v1/hecate/receipts/{id}

21.7. Regulatory applicability API

GET /pp/v1/regulatory/applicability

Inputs SHOULD include subject/company context, jurisdiction, reporting period, knowledge-time and requested purpose.

The response SHALL identify not only the answer but the assertion/mapping/evidence lineage supporting it.

21.8. Idempotency

All material mutation endpoints SHALL support an idempotency key.

Retries SHALL not mint duplicate PP identities or duplicate authority-bearing Decisions.

---

22. SSSR Registration Plan

22.1. Registration principle

Every production PP table SHALL have table-level SSSR metadata.

Every material field that may be consumed by a ZAYAZ engine, Agent, form, report, validator or evidence link SHOULD have an SSSR signal identity.

22.2. Registration sequence

For each migration:

SQL migration
    |
    v
schema introspection
    |
    v
SSSR candidate generation
    |
    v
SSSR validation
    |
    v
approved signal registration
    |
    v
CMID / SSSR reference available to consumers

22.3. No circular authority

SSSR describes where the field exists and how to address it.

The PP standard/schema describes what the PP field means.

SSSR SHALL link to PP semantic identity/schema where useful, but shall not redefine PP meaning.

---

23. Security, Tenancy and Isolation

Core 1.0 SHALL enforce:

authentication
authorisation
least privilege
security classification
tenant isolation
white-label isolation
encryption in transit
encryption at rest
access logging
tamper-evident audit events
secrets isolation
backup and recovery

23.1. Global and scoped knowledge

The implementation SHALL distinguish at least:

global canonical knowledge
Viroway internal knowledge
tenant-scoped knowledge
white-label-scoped knowledge
restricted/legal/confidential knowledge

A scope promotion SHALL require explicit review and rights/confidentiality checks.

23.2. Row-level security

PostgreSQL Row Level Security SHOULD be used for tenant/white-label operational tables where direct database enforcement materially reduces leakage risk.

Application-layer checks SHALL not be the only tenant isolation boundary for high-risk knowledge.

---

24. Audit, Provenance and Historical Reconstruction

24.1. Provenance minimum

Every material object/event SHALL preserve:

creator/actor
created/recorded time
source lineage
transformation lineage
review lineage
decision lineage
schema version
Registry versions
software/component version where relevant
digests

24.2. Historical query

Core 1.0 SHALL support questions of the form:

What was legally valid on date X?
What did PP know on date Y?
Which assertion version was approved at that time?
Which mapping was in force?
Which MRR projection had been released?
Which HECATE rules had been applied?
Which Runtime activation had occurred?

24.3. No retroactive reinterpretation

Historical replay SHALL distinguish:

exact reconstruction under the rules then in force

from:

re-evaluation using current rules or current interpretation

Both may be useful. They SHALL never be silently conflated.

---

25. Repository Package

25.1. Blueprint document

Recommended canonical path:

content/standards/pergamum-pulse/
  pergamum-pulse-core-1-0-implementation-blueprint.mdx

It SHALL be registered in PP-DREG before being treated as canonical PP corpus content.

25.2. Machine-readable Core manifest

Recommended new artefact:

config/system/pergamum-pulse/core-1.0-manifest.json

The manifest SHOULD identify:

Core version
required PP documents and versions
required Registries and versions
required object classes
required schema URIs
required HECATE baselines
required database migration set
required fixtures
source Git commit
manifest digest

25.3. Associated implementation package

Generated SQL, fixtures and example payloads SHOULD be stored under an associated-files package consistent with existing repository practice, for example:

code/associated-files/standards/pergamum-pulse/
  pergamum-pulse-core-1-0-implementation-blueprint/

Production migration placement SHALL follow the database deployment repository/convention actually used by ZAYAZ; this Blueprint does not create a second migration authority.

---

26. Implementation Build Order

The following is an engineering dependency order. Every group is part of Core 1.0; the numbering does not indicate optional MVP scope.

Build 1 — Freeze governed inputs

1. register this Blueprint in PP-DREG;
2. validate Object & Prefix Register;
3. validate lifecycle Registry;
4. validate rights vocabulary;
5. create/update Core 1.0 manifest;
6. enable strict VW-DL treatment for Core artefacts where migration prerequisites are satisfied.

Build 2 — Universal persistence

1. pp.object_identity;
2. pp.object_version;
3. lifecycle transitions;
4. bitemporal helpers/views;
5. authority envelopes;
6. scope/applicability envelopes;
7. provenance records;
8. relationships;
9. transactional outbox.

Build 3 — Source, capture and rights

1. source series/object/candidate;
2. admission decision;
3. immutable capture metadata;
4. authenticity assessment;
5. chain of custody;
6. rights objects;
7. rights Registry projections;
8. HECATE source/rights gates.

Build 4 — Document and semantic knowledge

1. page/representation model;
2. minimum document AST;
3. Knowledge Document;
4. Knowledge Section;
5. Source Fragment;
6. Knowledge Assertion;
7. Knowledge Entity;
8. relationship model;
9. citation;
10. HECATE knowledge/assertion gates.

Build 5 — Mapping and graph integration

1. relationship-type Registry;
2. mapping-type Registry;
3. Mapping Object;
4. Crosswalk Set;
5. mapping evidence/review/decision;
6. graph integrity rules;
7. historical traversal.

Build 6 — Change intelligence and projection

1. detection/difference objects;
2. impact/dependency assessment;
3. Change Candidate;
4. Change Decision;
5. Projection Manifest;
6. compiler execution;
7. Generated Artefact;
8. release/activation/rollback records;
9. deterministic projection checks.

Build 7 — Generic HECATE runtime

1. Profile and Rule Set resolver;
2. Rule engine;
3. Evidence Snapshot;
4. execution plan;
5. Findings;
6. gates;
7. receipts;
8. exceptions/remediation;
9. replay.

Build 8 — The four required bridges/profiles

1. Regulatory Temporal Profile;
2. PP-to-MRR Projection Contract;
3. PP-to-SSSR Bridge;
4. PP-to-TrustGate Evidence Contract.

Build 9 — Governed retrieval subset

1. retrieval eligibility;
2. chunking profile;
3. Knowledge Chunk;
4. metadata/full-text retrieval;
5. typed graph traversal;
6. Retrieval Request/Plan/Session/Result;
7. Context Package;
8. Grounding Record.

Build 10 — PP-VS-001

Execute the first complete regulatory acceptance slice.

---

27. PP-VS-001 — First Vertical Acceptance Slice

27.1. Purpose

PP-VS-001 proves that Pergamum Pulse Core 1.0 works as an end-to-end governed knowledge foundation.

The scenario is:

ESRS E1 / GHG emissions
Scope 2
Purchased electricity
Sweden
identified reporting period

The implementation SHALL use pinned official/authoritative source captures selected during fixture preparation. This Blueprint intentionally does not hard-code a legal conclusion or emission factor into the architecture document.

27.2. Test question

PP SHALL be able to answer:

For this company/context, reporting period and purchased-electricity activity, what reporting requirement and methodology apply, and why?

27.3. Required lineage

The answer SHALL traverse:

Source Series
 -> Source Object
 -> Source Capture
 -> Rights / Authenticity
 -> Knowledge Document
 -> Source Fragment
 -> Knowledge Assertion
 -> Regulatory temporal applicability
 -> Mapping
 -> Change Candidate
 -> Change Decision
 -> Projection Manifest
 -> generated MRR projection package
 -> HECATE receipt

27.4. Integration extension

The wider ZAYAZ vertical acceptance SHOULD continue:

MRR active rule
 -> Emission Factor Registry candidate/active record
 -> MICE factor resolver
 -> selected factor + rejected alternatives
 -> TrustGate evidence/decision
 -> ZARA explanation

MRR, the Emission Factor Registry and MICE are downstream systems and are not redefined as PP Core tables.

27.5. Acceptance assertions

The fixture SHALL prove:

1. the source capture digest is immutable;
2. the source version and legal/effective temporal events are queryable;
3. the exact Source Fragment supporting the relevant assertion resolves;
4. the assertion preserves normative force, authority, rights and applicability;
5. the mapping pins both source and target versions;
6. HECATE validates objective conformance without approving legal meaning;
7. the Change Decision is separate from the Change Candidate;
8. the MRR projection is generated from an approved Decision;
9. repeated projection with identical inputs produces the same digest;
10. the SSSR bridge can resolve material PP physical fields;
11. the TrustGate evidence event is digest-bound and replayable;
12. historical queries can reproduce the state as known at a prior transaction time;
13. a superseding source creates governed change intelligence rather than silently overwriting the previous state;
14. a rights withdrawal can block later retrieval/processing without erasing historical knowledge;
15. ZARA can explain the final reasoning using governed PP lineage rather than unsupported model memory.

27.6. Failure tests

PP-VS-001 SHALL also include negative fixtures for:

invalid prefix
missing source capture
changed capture digest
missing rights state
assertion without Source Fragment
invalid temporal overlap
mapping to unversioned target
Change Candidate without Decision
projection without eligible Decision
MRR package with broken lineage
SSSR binding to missing signal
TrustGate event with mismatched digest
historical replay using current rules silently

---

28. Definition of Done — PP Core 1.0

PP Core 1.0 is complete only when all of the following are true.

28.1. Corpus and Registry

• Blueprint registered in PP-DREG.
• All Core PP prefixes resolve in the Object & Prefix Register.
• No implementation code hard-codes governed lifecycle values that already exist in the lifecycle Registry.
• Rights operation and permission states resolve from the governed rights vocabulary.
• New Core Registries are schema-valid and HECATE-validatable.

28.2. Database

• Stable identities are separated from immutable versions.
• Bitemporal queries work for objects and relationships.
• Universal authority, scope and provenance contracts are implemented.
• Typed source, rights, knowledge, mapping, change and HECATE tables exist.
• Transactional outbox is implemented.
• Tenant/white-label isolation controls are tested.

28.3. Source and rights

• Source Object and Source Capture are separate.
• Capture bytes/digests are immutable.
• Authenticity assessments are preserved separately from authority.
• Rights Records and supporting rights objects are implemented.
• Processing eligibility cannot broaden rights.

28.4. Knowledge

• Knowledge Document/AST/Section/Fragment lineage is reproducible.
• Knowledge Assertions are typed and evidence-bound.
• entities/relationships are governed and versioned.
• mappings preserve evidence, direction, cardinality, authority and review.

28.5. Change and projection

• difference -> impact -> Candidate -> Decision -> Projection is implemented.
• projection inputs are pinned and reproducible.
• Generated Artefacts have digests.
• activation remains a separate authority step.
• rollback/historical lineage exists.

28.6. HECATE

• Generic HKCP execution model exists.
• all initial Core gates can execute.
• Findings and receipts are reproducible.
• HECATE does not silently mutate evaluated objects.

28.7. The four additions

• Regulatory Temporal Profile implemented.
• PP-to-MRR Projection Contract implemented.
• PP-to-SSSR Bridge implemented.
• PP-to-TrustGate Evidence Contract implemented.

28.8. Retrieval and explanation

• retrieval eligibility is enforced.
• first-slice chunks preserve source/rights/scope/time lineage.
• Context Package and Grounding Record can be produced.

28.9. Acceptance

• PP-VS-001 passes all positive tests.
• PP-VS-001 fails all intended negative fixtures.
• the final answer can be reconstructed from active output back to exact source evidence.

---

29. Explicitly Deferred Operational Expansion

The following are not required before Core 1.0 is considered architecturally complete, provided their governed contracts are compatible with this Blueprint:

• global automated source crawling;
• complete PDF layout/OCR optimisation for every document class;
• full translation infrastructure;
• high-scale dedicated graph database;
• vector database infrastructure;
• advanced hybrid retrieval/reranking;
• automated model evaluation farms;
• public Publication engine;
• complete Workbench user interface;
• large-scale crosswalk recommendation automation;
• advanced incident-management UI;
• fully automated disaster-recovery orchestration;
• all source-domain ingest profiles.

These are capability expansions, not missing constitutional foundations.

---

30. Key Engineering Decisions

30.1. No second Governance Kernel

Core 1.0 implements the existing PP standards. It does not create a competing kernel vocabulary.

30.2. PostgreSQL first

PostgreSQL is the canonical operational persistence layer for Core 1.0 structured knowledge and graph relationships.

Specialised indexes/stores may be derived later.

30.3. Object storage for immutable source bytes

Source bytes and large immutable artefacts belong in governed object storage with digests and references from PostgreSQL.

30.4. JSONB is extension, not semantic escape hatch

JSONB MAY carry governed extensible payloads. It SHALL not replace typed, schema-governed contracts for core semantics.

30.5. Transactional outbox for integration

SSSR/TrustGate/downstream notifications SHALL not depend on best-effort side effects inside database transactions.

30.6. Git remains schema/Registry authoring authority

PostgreSQL Registry tables are projections, not constitutional source files.

30.7. No automatic authority from AI

AI is permitted to propose. Authority-bearing decisions follow the PP governance path.

30.8. No automatic Runtime mutation from PP knowledge

Every operational change passes through CCPS projection and separate activation authority.

---

31. Core 1.0 Delivery Artefacts

The implementation programme SHALL produce at least:

1. this Blueprint;
2. updated PP Document Register;
3. Core 1.0 manifest;
4. new governed Registry JSON files;
5. Registry JSON Schemas;
6. Core common JSON Schemas;
7. source/right/knowledge/mapping/change/HECATE schemas;
8. Regulatory Temporal Profile schema;
9. SSSR bridge schema;
10. TrustGate evidence-event schema;
11. MRR projection-package schema;
12. PostgreSQL migration set;
13. seed/projection scripts for governed Registries;
14. HECATE Core Profile/Rule package;
15. SSSR registration package for PP physical schema;
16. PP-VS-001 fixture corpus;
17. positive/negative HECATE fixtures;
18. API OpenAPI contracts;
19. historical replay tests;
20. deterministic projection tests.

---

32. First Coding Boundary

Once this Blueprint is approved, architecture work SHOULD immediately transition into implementation artefacts in this order:

1. Core 1.0 manifest + Registry delta
2. common JSON Schemas
3. universal PostgreSQL migrations
4. source/capture/rights migrations + schemas
5. knowledge/assertion/entity migrations + schemas
6. mapping migrations + schemas
7. change/projection migrations + schemas
8. HECATE runtime schema + initial rules
9. Regulatory Temporal Profile
10. PP -> SSSR bridge
11. PP -> TrustGate evidence contract
12. PP -> MRR projection contract
13. PP-VS-001 fixture

The objective is no longer to produce another general architecture document.

The objective is to make the existing architecture executable.

---

33. Foundational Statement

Pergamum Pulse Core 1.0 is complete when ZAYAZ can preserve what a source is, what it says, what evidence supports an interpretation, when and where that interpretation applies, who or what approved it, what change it proposes, what executable artefact was derived from it, what was activated, and why — while retaining the ability to reconstruct every prior state without granting authority to inference, similarity, validation or trust scoring that those mechanisms do not possess.

The implementation sequence is therefore:

Build what is known.
Govern what it means.
Project what should change.
Validate what was produced.
Activate only through separate authority.
Preserve the evidence forever.
Then let ZARA explain and act on governed truth.

---