Skip to main content

Pergamum Pulse Retrieval, Embedding and AI Processing Profile

Version 0.1 — Governed Retrieval and AI Processing Contract​

This Profile defines how Pergamum Pulse knowledge may be prepared, indexed, retrieved, assembled into model context, processed by AI systems and converted into reviewable outputs.

It operationalises the knowledge, rights, semantic, change, security and historical-trust requirements established by the Pergamum Pulse framework and specifications.

It governs:

  • retrieval eligibility;
  • Retrieval Requests;
  • Retrieval Plans;
  • Retrieval Sessions;
  • chunk identity;
  • chunk boundaries;
  • chunk lineage;
  • lexical indexes;
  • semantic indexes;
  • graph indexes;
  • embedding generation;
  • embedding storage;
  • vector-store isolation;
  • hybrid retrieval;
  • metadata filters;
  • rights-aware retrieval;
  • authority-aware retrieval;
  • temporal retrieval;
  • tenant and white-label isolation;
  • ranking;
  • reranking;
  • diversity;
  • deduplication;
  • context assembly;
  • token-budget control;
  • RAG execution;
  • model selection;
  • Prompt Profiles;
  • system and task instructions;
  • tool access;
  • external-provider controls;
  • AI Processing Tasks;
  • Inference Records;
  • grounding;
  • citation;
  • uncertainty;
  • output classification;
  • human review;
  • prompt-injection defence;
  • data exfiltration defence;
  • model and embedding drift;
  • evaluation;
  • deletion propagation;
  • rights revocation;
  • index rebuild;
  • historical replay;
  • HECATE validation;
  • conformance.

The governing principles are:

Retrieval SHALL be treated as a governed decision over eligible knowledge, not as unconstrained search over all stored content.

A chunk, embedding, vector or model context SHALL remain a derived representation of its source and SHALL inherit applicable rights, confidentiality, tenant scope, temporal validity and provenance.

Semantic similarity SHALL NOT create truth, authority, applicability, equivalence or permission.

The retrieval layer SHALL preserve the distinction between source content, governed assertions, mappings, generated summaries and AI-generated interpretation.

Every material AI output SHALL remain traceable to its Retrieval Request, Retrieval Plan, retrieved objects, Context Package, model, Prompt Profile, tools, output and review state.

RAG SHALL improve grounding but SHALL NOT be represented as proof that an answer is correct, complete, current or authoritative.

Prompt instructions contained in retrieved content SHALL be treated as untrusted data unless explicitly authorised as governed instructions.

Rights restrictions SHALL apply before chunking, embedding, indexing, retrieval, context assembly, model processing and output publication.

Tenant, white-label, confidentiality and purpose boundaries SHALL be enforced at every retrieval and processing stage, including caches, logs, vectors, prompts and generated outputs.

Model confidence, retrieval score and reranker score SHALL NOT replace evidence, authority or human review.

Deletion, licence expiry and rights revocation SHALL propagate to chunks, embeddings, indexes, caches, Context Packages, evaluation datasets and downstream AI outputs.

Historical replay SHALL distinguish exact reconstruction from later semantic reinterpretation.

1. Scope​

This Profile applies to every Pergamum Pulse process that:

  • divides knowledge into chunks;
  • creates or updates search indexes;
  • creates embeddings;
  • stores vector representations;
  • performs lexical retrieval;
  • performs semantic retrieval;
  • performs graph retrieval;
  • performs hybrid retrieval;
  • reranks candidate results;
  • assembles context;
  • sends knowledge to an AI model;
  • invokes a tool from an AI process;
  • creates AI-assisted assertions, mappings, Candidates, summaries or Publications;
  • evaluates retrieval or AI quality;
  • caches model context or output;
  • deletes, rebuilds or migrates retrieval artefacts.

It applies to:

  • Source Objects;
  • Source Captures;
  • Rights Records;
  • Knowledge Documents;
  • Knowledge Sections;
  • Source Fragments;
  • Knowledge Assertions;
  • Knowledge Entities;
  • Knowledge Bundles;
  • Citation Objects;
  • Mapping Objects;
  • Crosswalk Sets;
  • Change Candidates;
  • Change Decisions;
  • Projection Manifests;
  • Publications;
  • tenant knowledge;
  • white-label knowledge;
  • global canonical knowledge;
  • internal Viroway knowledge.

This Profile does not itself:

  • grant rights;
  • approve source authority;
  • approve assertion meaning;
  • approve equivalence;
  • approve a Change Candidate;
  • issue a Change Decision;
  • activate Runtime state;
  • approve public Publication;
  • certify an organisation, product or process.

2. Normative Language​

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

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

Where a Rights Record, tenant contract, white-label agreement, security classification, approved ADR or domain Profile is more restrictive, the more restrictive condition prevails.

No implementation Profile SHALL weaken:

  • source identity;
  • rights;
  • scope;
  • tenant isolation;
  • white-label isolation;
  • confidentiality;
  • provenance;
  • temporal validity;
  • authority separation;
  • grounding;
  • citation;
  • deletion;
  • historical reconstruction;
  • activation boundaries.

3. Retrieval and AI Processing Architecture​

The canonical path is:

Governed Knowledge Objects
          │
          ▼
Retrieval Eligibility Gate
          │
          ▼
Chunking and Index Projection
          │
          ├── Lexical Index
          ├── Vector Index
          └── Graph Index
          │
          ▼
Retrieval Request
          │
          ▼
Retrieval Plan
          │
          ▼
Candidate Retrieval
          │
          ▼
Rights, Scope, Authority and Time Filters
          │
          ▼
Ranking, Reranking and Diversity Controls
          │
          ▼
Context Package
          │
          ▼
AI Processing Task
          │
          ▼
Model, Prompt and Tool Execution
          │
          ▼
Grounded Output and Citations
          │
          ▼
Review, Validation and Governed Downstream Use

The following SHALL remain distinct:

  • source content;
  • Source Fragment;
  • Knowledge Chunk;
  • embedding;
  • index entry;
  • Retrieval Result;
  • Context Package;
  • model input;
  • model output;
  • governed Knowledge Assertion;
  • Mapping Object;
  • Change Candidate;
  • Publication;
  • active Runtime state.

4. Canonical Retrieval and Processing Objects​

ObjectPrefixPurpose
Retrieval Eligibility RecordPP-RER-Records whether an object may be chunked, indexed, embedded or retrieved
Knowledge ChunkPP-CHK-Represents an addressable derived segment
Chunking ProfilePP-CHP-Defines deterministic chunking behaviour
Embedding RecordPP-EMB-Records one embedding and its lineage
Embedding ProfilePP-EMP-Defines embedding model and preprocessing
Retrieval IndexPP-IDX-Identifies a lexical, vector, graph or hybrid index
Index Build RecordPP-IBR-Records one deterministic index build
Retrieval RequestPP-RQ-Records the user's, Agent's or Component's retrieval intent
Retrieval PlanPP-RPL-Defines indexes, filters, ranking and limits
Retrieval SessionPP-RSE-Records one execution of a Retrieval Plan
Retrieval ResultPP-RRS-Represents one returned object or chunk
Reranking RecordPP-RRK-Records ranking transformation
Context PackagePP-CTX-Records the exact model context assembled
Prompt ProfilePP-PRP-Defines governed system and task instructions
Model ProfilePP-MDP-Defines approved model capabilities and restrictions
AI Processing TaskPP-AIT-Defines one governed AI task
AI Inference RecordPP-AIR-Records one model execution
Tool Invocation RecordPP-TIR-Records one AI-initiated tool invocation
Grounding RecordPP-GRD-Links output claims to retrieved evidence
AI Evaluation RecordPP-AEV-Records retrieval or model evaluation
Retrieval IncidentPP-RIN-Records retrieval, leakage, injection or indexing incidents
Deletion Propagation RecordPP-DPR-Records removal across retrieval and AI artefacts
Historical Processing RecordPP-HPR-Preserves historical retrieval and inference state

5. Retrieval Eligibility Gate​

No source-derived object SHALL be chunked, embedded, indexed, retrieved or sent to a model before eligibility is evaluated.

Rights eligibility SHALL be derived from the applicable canonical PP-RGT- Rights Record governed by PP-RLCPS.

The permitted_operations structure in a Retrieval Eligibility Record is a derived operational eligibility decision. It SHALL NOT constitute, replace or redefine the source Rights Record.

Where an eligibility operation corresponds directly to an PP-RLCPS processing right, the PP-RLCPS semantic SHALL be used.

An eligibility decision SHALL NOT broaden a permission granted by the Rights Record.

retrieval_eligibility:
  eligibility_id: PP-RER-000001
  object_id: PP-KD-000001
  object_version: 1.0.0

  permitted_operations:
    chunking: permitted
    lexical_indexing: permitted
    semantic_indexing: permitted
    embedding: permitted_with_conditions
    vector_storage: permitted_with_conditions
    retrieval: permitted
    rag: restricted
    external_model_processing: prohibited

  conditions:
    - internal_users_only
    - eu_data_residency

  status: eligible_with_conditions
  provenance: {}

5.1. Eligibility Inputs​

The Gate SHALL evaluate:

  • object identity;
  • object version;
  • Rights Records;
  • security classification;
  • confidentiality;
  • personal data;
  • tenant scope;
  • white-label scope;
  • permitted purpose;
  • jurisdiction;
  • retention;
  • deletion requirements;
  • source status;
  • review status;
  • lifecycle;
  • provenance.

5.2. Eligibility Outcomes​

Outcomes MAY include:

  • eligible;
  • eligible with conditions;
  • lexical indexing only;
  • metadata indexing only;
  • internal retrieval only;
  • no embeddings;
  • no vector storage;
  • no RAG;
  • no external model processing;
  • legal review required;
  • security review required;
  • tenant approval required;
  • prohibited;
  • quarantined;
  • unable to determine.

5.3. Eligibility Non-Authority​

Eligibility SHALL NOT establish source truth, assertion authority, semantic equivalence or Publication permission.

5.4. Eligibility Expiration​

Eligibility SHALL be re-evaluated where:

  • Rights Records change;
  • licence expires;
  • source status changes;
  • classification changes;
  • tenant contract changes;
  • model provider changes;
  • jurisdiction changes;
  • purpose changes;
  • retention expires.

6. Knowledge Chunk​

A Knowledge Chunk is a derived, addressable segment created for retrieval or processing.

knowledge_chunk:
  chunk_id: PP-CHK-000001
  chunk_version: 1.0.0

  source:
    object_id: PP-KD-000001
    object_version: 1.0.0
    section_id: PP-KS-000010
    source_fragments:
      - PP-SF-000101

  chunking_profile:
    profile_id: PP-CHP-000001
    profile_version: 1.0.0

  position:
  sequence: 10

  offset:
    type: unicode_character
    start: 2400
    end: 3910

  structural_locator:
    document_section: "4.2"
    heading_path:
      - "Part II"
      - "Rights Model"
      - "Processing Rights"

  content_digest: sha256:...
  language: en
  token_count: 412

  rights: {}
  scope: {}
  temporal: {}
  provenance: {}

6.1. Chunk Identity​

Every chunk SHALL possess an immutable PP-CHK- identifier.

6.2. Chunk Source​

Every chunk SHALL link to:

  • source object;
  • source version;
  • section or fragment where available;
  • exact source offsets or structural locator;
  • chunking Profile;
  • content digest;
  • provenance.

6.3. Chunk Non-Authority​

A chunk SHALL NOT be treated as:

  • the complete source;
  • a complete requirement;
  • an approved assertion;
  • an authoritative summary;
  • a publication-ready quotation.

6.4. Chunk Rights​

A chunk SHALL inherit applicable source and fragment rights.

6.5. Chunk Scope​

A chunk SHALL inherit tenant, white-label, confidentiality and jurisdiction scope.

6.6. Chunk Immutability​

A chunk version SHALL be immutable.

A source or chunking change SHALL create a new chunk version or identifier according to the declared identity policy.

7. Chunking Profile​

A Chunking Profile defines deterministic segmentation.

chunking_profile:
  profile_id: PP-CHP-000001
  profile_version: 1.0.0
  strategy: structure_aware
  maximum_tokens: 600
  target_tokens: 450
  overlap_tokens: 50
  preserve_headings: true
  preserve_tables: true
  preserve_lists: true
  preserve_citations: true
  prohibited_splits:
    - formula
    - table_row
    - definition_term

7.1. Chunking Strategies​

Strategies MAY include:

  • structural;
  • semantic;
  • sentence-window;
  • paragraph;
  • clause;
  • table-aware;
  • code-aware;
  • graph-derived;
  • fixed-token;
  • hybrid.

7.2. Structural Integrity​

Chunking SHOULD preserve:

  • heading lineage;
  • list structure;
  • table relationships;
  • formula boundaries;
  • footnotes;
  • citation anchors;
  • conditions;
  • exceptions;
  • units;
  • defined terms.

7.3. Overlap​

Overlap SHALL be explicit and SHALL not create untracked duplicate evidence.

7.4. Chunk Completeness​

Chunk metadata SHOULD identify whether a chunk:

  • is self-contained;
  • depends on prior context;
  • depends on following context;
  • contains a partial table;
  • contains a partial formula;
  • contains a definition reference;
  • contains an unresolved cross-reference.

7.5. Determinism​

Identical source content and Profile SHOULD produce identical chunk boundaries and digests.

7.6. Semantic Chunking​

Semantic chunking using an AI model SHALL record:

  • model;
  • model version;
  • Prompt Profile;
  • parameters;
  • seed where available;
  • review or validation;
  • reproducibility limitations.

8. Chunking Restrictions​

Chunking SHALL NOT:

  • remove required attribution;
  • strip rights metadata;
  • remove source locators;
  • merge tenant content;
  • merge different Rights Records without preserving restrictions;
  • conceal exceptions;
  • separate thresholds from units;
  • separate formulas from variable definitions;
  • transform unknown into absent;
  • treat a heading as source evidence without content;
  • copy prohibited content into an unrestricted index.

8.1. Restricted Source​

A restricted source MAY be:

  • metadata indexed;
  • locally chunked;
  • encrypted;
  • excluded from embeddings;
  • excluded from external processing;
  • retrieved only for authorised Roles.

8.2. Redacted Chunk​

A redacted chunk SHALL preserve:

  • redaction reason;
  • authority;
  • removed span;
  • replacement token;
  • retrieval restrictions;
  • provenance.

8.3. Fragment-Level Rights​

Fragment-level rights SHALL override broader document rights where more restrictive.

9. Embedding Profile​

An Embedding Profile defines how text or structured knowledge is converted to a vector representation.

embedding_profile:
  profile_id: PP-EMP-000001
  profile_version: 1.0.0

  model:
    model_profile_id: PP-MDP-000101
    model_name: example-embedding-model
    model_version: "2026-07"
    dimensions: 3072

  preprocessing:
    unicode_normalisation: NFC
    whitespace_normalisation: controlled
    include_headings: true
    include_metadata:
      - canonical_name
      - entity_type
      - jurisdiction

  storage:
    vector_index_id: PP-IDX-000201
    encryption: required

  rights_policy:
    external_processing: prohibited
    vector_storage: permitted

  provenance: {}

9.1. Required Profile Fields​

Every Embedding Profile SHALL identify:

  • Profile identity;
  • Profile version;
  • embedding model;
  • model version;
  • dimensions;
  • input representation;
  • preprocessing;
  • truncation behaviour;
  • language handling;
  • metadata inclusion;
  • normalisation;
  • provider;
  • processing location;
  • retention;
  • security;
  • rights policy;
  • provenance.

9.2. Model Version Pinning​

Embedding model versions SHALL be pinned.

A mutable provider alias without a pinned underlying version SHALL not be used for historically assured embeddings.

9.3. Input Representation​

The Profile SHALL identify whether the embedding input contains:

  • chunk text;
  • heading path;
  • document title;
  • entity labels;
  • assertion structure;
  • metadata;
  • source locator;
  • controlled synonyms;
  • tenant-specific augmentation.

9.4. Hidden Metadata​

Sensitive metadata SHALL NOT be added to embedding input unless authorised for that index and purpose.

9.5. Truncation​

Truncation SHALL be explicit.

A truncated input SHALL record:

  • original token count;
  • embedded token count;
  • truncation position;
  • omitted content;
  • expected impact;
  • provenance.

9.6. Multilingual Embeddings​

Multilingual Profiles SHALL identify:

  • supported languages;
  • language detection;
  • translation use;
  • cross-language retrieval expectations;
  • evaluation;
  • known limitations.

9.7. Embedding Non-Reversibility Assumption​

Embeddings SHALL be treated as potentially information-bearing and sensitive even where direct text reconstruction is not intended.

10. Embedding Record​

Every embedding SHALL be represented by an Embedding Record.

embedding_record:
  embedding_id: PP-EMB-000001
  embedding_version: 1.0.0

  source:
    chunk_id: PP-CHK-000001
    chunk_version: 1.0.0
    content_digest: sha256:...

  embedding_profile:
    profile_id: PP-EMP-000001
    profile_version: 1.0.0

  model:
    model_profile_id: PP-MDP-000101
    model_version: "2026-07"

  vector:
    storage_reference: vector://pp-index/internal/000001
    dimensions: 3072
    vector_digest: sha256:...

  generated_at: 2026-08-04T20:00:00Z
  rights: {}
  scope: {}
  status: active
  provenance: {}

10.1. Required Embedding Fields​

Every Embedding Record SHALL preserve:

  • embedding identity;
  • embedding version;
  • source chunk;
  • source chunk version;
  • content digest;
  • Embedding Profile;
  • model identity;
  • model version;
  • vector dimensions;
  • storage location;
  • vector digest where feasible;
  • generation time;
  • rights;
  • scope;
  • lifecycle;
  • provenance.

10.2. Embedding Identity​

An embedding SHALL not be identified only by its vector value.

10.3. Embedding Versioning​

A new Embedding Record or version SHALL be created where:

  • source chunk changes;
  • preprocessing changes;
  • model changes;
  • dimensions change;
  • Profile changes;
  • rights treatment changes;
  • tenant scope changes.

10.4. Embedding Lifecycle​

States MAY include:

  • pending;
  • active;
  • stale;
  • restricted;
  • quarantined;
  • superseded;
  • deletion pending;
  • deleted with tombstone;
  • historical only.

10.5. Embedding Rights​

Embedding rights SHALL remain traceable to source Rights Records.

10.6. Embedding Deletion​

Deletion SHALL preserve a tombstone and Deletion Propagation Record where lawful.

11. Retrieval Index​

Every index SHALL be a governed object.

retrieval_index:
  index_id: PP-IDX-000001
  index_version: 1.0.0
  index_type: hybrid

  included_object_types:
    - knowledge_chunk
    - knowledge_assertion
    - knowledge_entity

  scope:
    knowledge_scope: global_canonical
    tenant_scope:
      mode: none

  retrieval_methods:
    - lexical
    - vector
    - graph

  build_record: PP-IBR-000001
  status: active
  provenance: {}

11.1. Index Types​

Index types MAY include:

  • lexical;
  • vector;
  • graph;
  • metadata;
  • temporal;
  • geospatial;
  • code;
  • hybrid;
  • federated.

11.2. Index Scope​

Every index SHALL identify:

  • object classes;
  • knowledge scope;
  • tenant scope;
  • white-label scope;
  • security classification;
  • jurisdictions;
  • languages;
  • permitted purposes;
  • rights conditions;
  • retention;
  • provenance.

11.3. Index Isolation​

Restricted, tenant and white-label content SHALL be isolated by enforceable policy and storage architecture.

Logical filters alone SHALL not be the sole boundary where risk requires physical or cryptographic separation.

11.4. Index Versioning​

An index version SHALL identify:

  • included object snapshot;
  • build Profile;
  • model and tokenizer versions;
  • schema;
  • filters;
  • ranking configuration;
  • build time;
  • digest;
  • provenance.

11.5. Index Non-Authority​

Index presence and rank SHALL NOT create authority or truth.

12. Index Build Record​

Every material build SHALL create an Index Build Record.

index_build:
  build_id: PP-IBR-000001
  index_id: PP-IDX-000001
  index_version: 1.0.0

  inputs:
    object_snapshot_digest: sha256:...
    chunking_profiles:
      - PP-CHP-000001@1.0.0
    embedding_profiles:
      - PP-EMP-000001@1.0.0

  build_component:
    component_id: component.pergamum.index-builder
    version: 2.3.0

  started_at: 2026-08-04T20:00:00Z
  completed_at: 2026-08-04T20:07:00Z
  status: succeeded

  output_digest: sha256:...
  provenance: {}

12.1. Build Inputs​

Build inputs SHALL be pinned and digest-verifiable.

12.2. Build Determinism​

Lexical and metadata index builds SHOULD be reproducible from identical inputs and configuration.

Vector index ordering MAY vary, but included records and vector digests SHALL remain reconcilable.

12.3. Incremental Build​

An incremental build SHALL identify:

  • base index version;
  • additions;
  • updates;
  • deletions;
  • failed records;
  • resulting digest;
  • consistency validation.

12.4. Failed Records​

Failed chunks or objects SHALL not silently disappear.

They SHALL produce:

  • failure records;
  • retry state;
  • index completeness impact;
  • provenance.

12.5. Index Completeness​

Build metadata SHOULD expose:

  • eligible objects;
  • indexed objects;
  • excluded objects;
  • failed objects;
  • stale objects;
  • deletion-pending objects;
  • completeness percentage;
  • limitations.

13. Lexical Retrieval​

Lexical retrieval MAY use:

  • exact term;
  • phrase;
  • fielded search;
  • controlled synonym;
  • fuzzy term;
  • prefix;
  • stemming;
  • language-specific analysis;
  • Boolean query.

13.1. Query Preservation​

The executed lexical query SHALL be preserved.

13.2. Controlled Synonyms​

Synonyms SHALL originate from governed dictionaries, aliases, entities or Mapping Objects.

Automatically generated synonyms SHALL remain candidates until approved or SHALL be marked as heuristic.

Exact identifiers SHOULD receive deterministic priority where the user or process provides a recognised identifier.

13.4. Defined Terms​

Retrieval SHOULD preserve distinctions among:

  • exact defined term;
  • alias;
  • acronym;
  • colloquial label;
  • translated label;
  • deprecated term.

13.5. Fuzzy Retrieval​

Fuzzy matching SHALL not cause automatic entity merge or equivalence.

14. Vector Retrieval​

Vector retrieval SHALL preserve:

  • query embedding Profile;
  • query model version;
  • target index;
  • distance metric;
  • candidate count;
  • score;
  • filters;
  • threshold;
  • provenance.
vector_retrieval:
  query_embedding_profile: PP-EMP-000001@1.0.0
  index_id: PP-IDX-000201
  index_version: 3.0.0
  metric: cosine
  candidate_limit: 100
  minimum_score: 0.72

14.1. Distance Metric​

The distance or similarity metric SHALL be declared.

14.2. Score Interpretation​

Similarity scores SHALL be treated as index- and model-specific.

They SHALL not be compared across incompatible models or indexes without calibration.

14.3. Thresholds​

Thresholds SHALL be evaluation-supported and purpose-specific.

Approximate-nearest-neighbour configuration SHALL identify:

  • algorithm;
  • parameters;
  • recall expectations;
  • latency targets;
  • reproducibility limitations;
  • version.

14.5. Vector Non-Authority​

Vector proximity SHALL NOT establish:

  • semantic identity;
  • factual support;
  • legal applicability;
  • equivalence;
  • rights;
  • authority.

15. Graph Retrieval​

Graph retrieval SHALL use governed nodes, relationships and Mapping Objects.

A Graph Retrieval Plan SHALL identify:

  • starting nodes;
  • relationship types;
  • direction;
  • depth;
  • path constraints;
  • temporal view;
  • authority filters;
  • rights filters;
  • tenant scope;
  • conflict policy;
  • result limits.
graph_retrieval:
  start_nodes:
    - PP-KE-000101
  relationship_types:
    - supported_by
    - maps_to
  direction: outbound
  maximum_depth: 3
  valid_at: 2026-08-04T00:00:00Z

15.1. Relationship Constraints​

Only permitted relationship types SHALL be traversed.

15.2. Explainable Paths​

Every material result SHOULD expose the graph path used.

15.3. Conflict Handling​

Conflicted relationships SHALL be:

  • included with warning;
  • excluded;
  • separately grouped;
  • or blocked

according to the Retrieval Plan.

15.4. Historical Graph Retrieval​

Historical retrieval SHALL use the graph as it existed at the requested valid and transaction times.

15.5. Inference​

Graph inference SHALL preserve inference Rules, inputs, output confidence and provenance.

16. Hybrid Retrieval​

Hybrid retrieval MAY combine:

  • lexical retrieval;
  • vector retrieval;
  • graph retrieval;
  • metadata retrieval;
  • deterministic identifier lookup;
  • curated bundles;
  • recency or temporal relevance;
  • authority weighting.

16.1. Fusion Method​

The fusion method SHALL be declared.

Methods MAY include:

  • reciprocal-rank fusion;
  • weighted score fusion;
  • cascade;
  • interleaving;
  • rule-based union;
  • learned fusion.

16.2. Score Normalisation​

Score normalisation SHALL identify method, calibration data and limitations.

16.3. Method Contribution​

A Retrieval Result SHOULD preserve which methods contributed to its rank.

16.4. Deterministic Priority​

Exact governed identifiers, explicit citations and user-selected objects MAY receive deterministic priority.

16.5. Hybrid Non-Authority​

Fusion SHALL not transform multiple weak signals into authority without evidence.

17. Retrieval Request​

Every material retrieval SHALL have a Retrieval Request.

retrieval_request:
  request_id: PP-RQ-000001
  requester:
    actor_type: agent
    actor_id: agent.pergamum.knowledge-review

  purpose: assertion_review
  query_text: "Which source clauses support the device protocol capability?"
  query_language: en

  scope:
    tenant_scope:
      mode: none
    knowledge_scope:
      - global_canonical

  requested_object_types:
    - source_fragment
    - knowledge_assertion

  valid_at: 2026-08-04T00:00:00Z
  created_at: 2026-08-04T20:15:00Z
  provenance: {}

17.1. Required Request Fields​

A Retrieval Request SHALL identify:

  • Request identity;
  • requester;
  • purpose;
  • query or object request;
  • scope;
  • tenant context;
  • white-label context;
  • temporal context;
  • requested object classes;
  • output sensitivity;
  • provenance.

17.2. Requester Classes​

Requesters MAY include:

  • human user;
  • AI Agent;
  • Component;
  • workflow;
  • validator;
  • auditor;
  • external authorised system.

17.3. Purpose Binding​

Retrieval permission SHALL be evaluated against declared purpose.

17.4. Query Confidentiality​

Queries MAY themselves contain confidential or personal information and SHALL be classified accordingly.

17.5. Unbounded Request​

Unbounded retrieval SHALL be prohibited for restricted stores unless explicitly authorised.

18. Retrieval Plan​

A Retrieval Plan converts a Request into an executable governed search strategy.

retrieval_plan:
  plan_id: PP-RPL-000001
  plan_version: 1.0.0
  request_id: PP-RQ-000001

  indexes:
    - index_id: PP-IDX-000001
      index_version: 3.0.0
      method: lexical
    - index_id: PP-IDX-000201
      index_version: 3.0.0
      method: vector
    - index_id: PP-IDX-000301
      index_version: 2.0.0
      method: graph

  filters:
    rights: enforce
    tenant: enforce
    white_label: enforce
    valid_at: 2026-08-04T00:00:00Z
    lifecycle:
      include:
        - active
        - historical_only

  ranking:
    fusion_method: reciprocal_rank_fusion
    reranker_profile: PP-RRK-PROFILE-000001
    result_limit: 20

  context_budget:
    maximum_tokens: 12000

  provenance: {}

18.1. Required Plan Fields​

Every material Plan SHALL identify:

  • Plan identity;
  • Plan version;
  • Request;
  • indexes;
  • retrieval methods;
  • filters;
  • ranking;
  • reranking;
  • result limits;
  • context budget;
  • deduplication;
  • diversity treatment;
  • conflict policy;
  • fallback behaviour;
  • provenance.

18.2. Policy Compilation​

A Plan MAY be compiled from:

  • user permissions;
  • Agent Profile;
  • purpose;
  • Rights Records;
  • security classification;
  • tenant scope;
  • model context limitations;
  • approved retrieval policy.

18.3. Plan Review​

High-impact or sensitive retrieval Plans MAY require review before execution.

18.4. Fallback​

Fallback SHALL not broaden rights, tenant scope or confidentiality boundaries.

18.5. Plan Immutability​

An executed Plan version SHALL be immutable.

19. Retrieval Filters​

Filters SHALL be applied before content becomes available to the requester or model.

Required filters MAY include:

  • Rights Record;
  • purpose;
  • security classification;
  • confidentiality;
  • tenant;
  • white-label operator;
  • jurisdiction;
  • language;
  • object type;
  • lifecycle;
  • review state;
  • authority;
  • applicability;
  • valid time;
  • transaction time;
  • source status;
  • conflict state;
  • Publication eligibility.

19.1. Filter Order​

Security, rights and tenant filters SHALL execute before ranking where feasible.

19.2. Post-Filter Risk​

Post-retrieval filtering alone SHALL not be relied upon where prohibited content may be exposed to a model or external service before removal.

19.3. Filter Provenance​

The executed filters and versions SHALL be preserved.

19.4. Controlled Redaction​

A result MAY be returned in redacted form where policy permits.

19.5. Exclusion Explanation​

The system MAY expose a non-sensitive explanation that results were excluded without revealing restricted object existence.

20. Ranking and Reranking​

Ranking SHALL preserve:

  • candidate set;
  • initial scores;
  • score types;
  • fusion method;
  • reranker;
  • reranker version;
  • final scores;
  • exclusions;
  • provenance.

20.1. Ranking Features​

Features MAY include:

  • exact identifier match;
  • lexical relevance;
  • semantic similarity;
  • graph proximity;
  • source authority;
  • evidence quality;
  • applicability;
  • temporal relevance;
  • freshness;
  • review status;
  • user-selected scope.

20.2. Authority Weighting​

Authority weighting MAY improve ordering but SHALL not hide lower-authority conflicting evidence.

20.3. Recency​

Recency SHALL not automatically outrank historically applicable or legally controlling content.

20.4. Reranker Profile​

A Reranker Profile SHALL identify:

  • model or algorithm;
  • version;
  • input fields;
  • maximum candidates;
  • score range;
  • calibration;
  • rights;
  • processing location;
  • known bias;
  • evaluation;
  • provenance.

20.5. Reranker Input​

Restricted source text SHALL not be sent to an unauthorised reranker.

20.6. Ranking Non-Authority​

A higher rank SHALL not be interpreted as higher truth or legal authority unless ranking criteria explicitly support and disclose that interpretation.

21. Diversity and Deduplication​

Retrieval SHOULD avoid unnecessary duplication while preserving meaningful disagreement.

21.1. Duplicate Classes​

Duplicates MAY include:

  • identical chunk;
  • overlapping chunk;
  • duplicate source copy;
  • duplicate assertion;
  • same entity description;
  • mirrored web source;
  • translated version;
  • superseded version.

21.2. Deduplication Non-Destruction​

Deduplication SHALL not erase:

  • source diversity;
  • authority differences;
  • jurisdictional differences;
  • version differences;
  • rights differences;
  • conflicting assertions.

21.3. Diversity Dimensions​

Diversity MAY consider:

  • source;
  • publisher;
  • authority;
  • jurisdiction;
  • version;
  • viewpoint;
  • evidence class;
  • object type.

21.4. Result Clustering​

Results MAY be clustered by entity, source, topic, conflict or version.

Clustering SHALL preserve individual result identities and citations.

22. Retrieval Session​

Every material execution SHALL create a Retrieval Session.

retrieval_session:
  session_id: PP-RSE-000001
  request_id: PP-RQ-000001
  plan_id: PP-RPL-000001
  plan_version: 1.0.0

  executed_by:
    component_id: component.pergamum.retrieval-orchestrator
    version: 3.2.0

  started_at: 2026-08-04T20:15:01Z
  completed_at: 2026-08-04T20:15:02Z
  status: succeeded

  result_ids:
    - PP-RRS-000001
    - PP-RRS-000002

  provenance: {}

22.1. Session Status​

States MAY include:

  • queued;
  • running;
  • succeeded;
  • partially succeeded;
  • failed;
  • blocked;
  • cancelled;
  • timed out;
  • quarantined.

22.2. Partial Success​

Partial success SHALL identify:

  • failed indexes;
  • failed filters;
  • missing object classes;
  • completeness impact;
  • fallback used;
  • provenance.

22.3. Session Isolation​

Session data SHALL be isolated according to tenant, white-label, security and rights scope.

22.4. Session Retention​

Retention SHALL be purpose- and classification-aware.

23. Retrieval Result​

Every returned item SHALL be represented by a Retrieval Result.

retrieval_result:
  result_id: PP-RRS-000001
  session_id: PP-RSE-000001

  object:
    object_id: PP-CHK-000001
    object_version: 1.0.0
    object_type: knowledge_chunk

  retrieval_methods:
    lexical:
      rank: 2
      score: 12.4
    vector:
      rank: 1
      score: 0.84
    graph:
      path_id: PP-GPATH-000001

  final_rank: 1
  final_score: 0.92

  filters:
    rights_passed: true
    tenant_passed: true
    temporal_passed: true

  provenance: {}

23.1. Required Result Fields​

A result SHALL preserve:

  • Result identity;
  • Session;
  • object identity;
  • object version;
  • retrieval methods;
  • scores and ranks;
  • filters;
  • source and citation references;
  • rights;
  • scope;
  • temporal validity;
  • conflict state;
  • provenance.

23.2. Score Non-Comparability​

Scores from different methods SHALL remain distinguishable.

23.3. Result Snippet​

A result snippet SHALL preserve:

  • source chunk;
  • snippet offsets;
  • truncation;
  • highlighting;
  • rights;
  • provenance.

23.4. Result Authority​

The result SHALL expose authority metadata where material.

23.5. Result Exclusion​

A result removed by reranking, filtering or deduplication SHOULD remain auditable without being exposed to unauthorised consumers.

24. Context Package​

A Context Package records the exact governed knowledge assembled for an AI task.

context_package:
  context_id: PP-CTX-000001
  context_version: 1.0.0
  retrieval_session_id: PP-RSE-000001

  included_results:
    - result_id: PP-RRS-000001
      token_count: 420
      context_position: 1
    - result_id: PP-RRS-000002
      token_count: 380
      context_position: 2

  instructions:
    system_prompt_profile: PP-PRP-000001@1.0.0
    task_prompt_profile: PP-PRP-000101@2.0.0

  token_budget:
    maximum: 12000
    used: 10240

  rights: {}
  scope: {}
  digest: sha256:...
  provenance: {}

24.1. Required Context Fields​

Every material Context Package SHALL identify:

  • Context identity;
  • version;
  • Retrieval Session;
  • included results;
  • ordering;
  • token counts;
  • truncation;
  • system and task Prompt Profiles;
  • rights;
  • tenant and white-label scope;
  • security classification;
  • model eligibility;
  • digest;
  • provenance.

24.2. Context Ordering​

Ordering rules SHALL be declared.

24.3. Context Budget​

The budget SHALL identify:

  • maximum tokens;
  • reserved instruction tokens;
  • reserved output tokens;
  • included evidence tokens;
  • truncation strategy;
  • overflow behaviour.

24.4. Context Completeness​

The Context Package SHOULD identify:

  • included source coverage;
  • excluded high-ranked results;
  • omitted conflicts;
  • omitted rights-restricted evidence;
  • known gaps.

24.5. Context Non-Authority​

Inclusion in context SHALL not create authority.

24.6. Context Immutability​

A used Context Package version SHALL be immutable.

25. Context Selection​

Context selection SHALL optimise relevance without sacrificing:

  • rights;
  • scope;
  • evidence diversity;
  • authority disclosure;
  • conflict visibility;
  • temporal validity;
  • citation completeness.

25.1. Conflict Inclusion​

Where the task requires analysis of disputed knowledge, competing assertions SHOULD be included together where rights permit.

25.2. Source Coverage​

Context SHOULD avoid overrepresenting one duplicated source.

25.3. Lost-in-the-Middle Risk​

Long contexts SHOULD use ordering, summarisation or hierarchical retrieval strategies validated for the task.

25.4. Context Compression​

Compression MAY use:

  • extractive selection;
  • structured assertion representation;
  • table normalisation;
  • graph summaries;
  • governed summaries;
  • AI-generated summaries.

AI-generated context compression SHALL preserve source links, model provenance, uncertainty and review status.

25.5. Compression Non-Substitution​

A generated summary SHALL not silently replace available source evidence for high-impact decisions.

26. Prompt Profile​

A Prompt Profile governs instructions used for retrieval or AI processing.

prompt_profile:
  prompt_profile_id: PP-PRP-000001
  prompt_profile_version: 1.0.0
  prompt_class: system

  purpose: grounded_knowledge_analysis

  instruction_template: |
    Use only the provided governed context for source-derived claims.
    Distinguish source content from inference.
    Cite supporting objects.

  permitted_tools:
    - tool.pergamum.graph-read

  prohibited_actions:
    - grant_rights
    - approve_change
    - activate_runtime

  injection_policy: treat_retrieved_instructions_as_untrusted_data
  provenance: {}

26.1. Prompt Classes​

Prompt classes MAY include:

  • system;
  • developer;
  • task;
  • retrieval-query;
  • extraction;
  • classification;
  • summarisation;
  • mapping;
  • Candidate drafting;
  • evaluation;
  • safety;
  • citation;
  • tool-use.

26.2. Prompt Versioning​

Material instruction changes SHALL create a new Profile version.

26.3. Prompt Ownership​

Every Prompt Profile SHALL identify owning Module and Component.

26.4. Prompt Authority​

Prompt instructions SHALL not grant the model authority beyond the calling Agent, Component and workflow.

26.5. Prompt Secrets​

Secrets SHALL not be stored in Prompt Profiles.

26.6. Dynamic Prompt Content​

Dynamic content SHALL be separately delimited from governed instructions.

27. Instruction Hierarchy and Trust​

Instruction sources SHALL be classified.

27.1. Governed Instructions​

Governed instructions originate from approved Prompt Profiles, Agent Profiles, workflow policy or constitutional controls.

27.2. User Instructions​

User instructions are subject to permissions, purpose and safety controls.

27.3. Retrieved Content​

Retrieved content SHALL be treated as data, not instruction, unless the task explicitly retrieves governed instruction objects.

27.4. Tool Output​

Tool output SHALL be treated according to its source, schema, rights and trust level.

27.5. Instruction Conflict​

Conflicts SHALL be resolved by governed instruction precedence, not by position in retrieved content.

27.6. Delimitation​

Context Packages SHOULD clearly delimit:

  • system instructions;
  • task instructions;
  • user input;
  • retrieved source content;
  • tool output;
  • prior model output.

28. Prompt-Injection Defence​

The system SHALL defend against instructions embedded in:

  • documents;
  • web pages;
  • metadata;
  • comments;
  • code;
  • tables;
  • images;
  • OCR text;
  • tool output;
  • tenant content;
  • prior model output.

28.1. Injection Controls​

Controls MAY include:

  • instruction/data separation;
  • content labelling;
  • schema validation;
  • sanitisation;
  • trusted-instruction allowlists;
  • tool permission enforcement;
  • output filtering;
  • context segmentation;
  • model-side policy;
  • human review.

28.2. Injection Detection​

Detected injection attempts SHALL create:

  • a Finding;
  • a result annotation;
  • a blocked or quarantined state;
  • an Incident where material;
  • provenance.

28.3. Injection Non-Execution​

Retrieved instructions SHALL not alter:

  • permissions;
  • system prompts;
  • tool access;
  • tenant scope;
  • rights;
  • Publication state;
  • activation state.

28.4. Indirect Injection​

External content fetched by tools SHALL receive the same treatment as directly retrieved content.

29. Model Profile​

Every approved AI model SHALL possess a Model Profile.

model_profile:
  model_profile_id: PP-MDP-000001
  model_profile_version: 1.0.0

  provider: example-provider
  model_name: example-reasoning-model
  model_version: "2026-07-15"

  deployment:
    environment: viroway-controlled
    region: eu
    data_retention: none
    provider_training_use: prohibited

  capabilities:
    text_generation: true
    structured_output: true
    tool_use: true
    embeddings: false

  approved_tasks:
    - knowledge_analysis
    - assertion_candidate_generation

  prohibited_tasks:
    - final_legal_decision
    - rights_approval
    - runtime_activation

  provenance: {}

29.1. Required Model Fields​

Every Model Profile SHALL identify:

  • Profile identity;
  • Profile version;
  • provider;
  • model name;
  • pinned model version where available;
  • deployment;
  • region;
  • retention;
  • provider training use;
  • input modalities;
  • output modalities;
  • context limits;
  • capabilities;
  • approved tasks;
  • prohibited tasks;
  • security;
  • privacy;
  • evaluation;
  • known limitations;
  • provenance.

29.2. Mutable Provider Models​

Where the provider does not expose a fixed model version, the Profile SHALL disclose the limitation and strengthen evaluation and historical replay controls.

29.3. Model Substitution​

Automatic model substitution SHALL be prohibited unless an approved routing Profile defines:

  • eligible substitutes;
  • equivalence criteria;
  • risk;
  • evaluation;
  • logging;
  • fallback;
  • provenance.

29.4. Local and External Models​

Profiles SHALL distinguish:

  • Viroway-controlled;
  • tenant-controlled;
  • white-label-controlled;
  • external hosted;
  • on-device;
  • browser;
  • confidential-computing deployment.

29.5. Model Authority​

A Model Profile SHALL never assign legal, constitutional, certification or Runtime authority to the model.

30. AI Processing Task​

Every material AI operation SHALL be represented as an AI Processing Task.

ai_processing_task:
  task_id: PP-AIT-000001
  task_version: 1.0.0
  task_type: assertion_candidate_generation

  purpose: extract device capability assertions

  requester:
    actor_type: agent
    actor_id: agent.pergamum.assertion-extractor

  context_package:
    context_id: PP-CTX-000001
    context_version: 1.0.0

  model_profile:
    profile_id: PP-MDP-000001
    profile_version: 1.0.0

  prompt_profiles:
    - PP-PRP-000001@1.0.0
    - PP-PRP-000101@2.0.0

  output_contract:
    schema_id: pp.schema.assertion-candidate
    schema_version: 1.0.0

  review_requirement: mandatory
  provenance: {}

30.1. Task Types​

Task types MAY include:

  • classification;
  • entity extraction;
  • assertion extraction;
  • relationship candidate generation;
  • mapping candidate generation;
  • summarisation;
  • translation;
  • comparison;
  • semantic difference analysis;
  • rights-risk identification;
  • Change Candidate drafting;
  • test generation;
  • documentation assistance;
  • question answering;
  • retrieval planning;
  • reranking;
  • evaluation;
  • anomaly detection.

30.2. Required Task Fields​

Every Task SHALL identify:

  • Task identity;
  • Task version;
  • task type;
  • purpose;
  • requester;
  • tenant and white-label context;
  • Context Package;
  • Model Profile;
  • Prompt Profiles;
  • permitted tools;
  • output contract;
  • review requirement;
  • retention;
  • rights;
  • security classification;
  • provenance.

30.3. Purpose Limitation​

A Context Package retrieved for one purpose SHALL not be reused for a materially different purpose without renewed eligibility.

30.4. High-Impact Tasks​

Tasks concerning legal obligations, rights, certification, safety, formulas, financial impact, public claims, tenant controls or Runtime change SHALL require mandatory competent review.

30.5. Task Non-Authority​

Task execution SHALL NOT create approval or activation.

31. AI Inference Record​

Every model execution SHALL create an AI Inference Record.

ai_inference:
  inference_id: PP-AIR-000001
  task_id: PP-AIT-000001

  model:
    profile_id: PP-MDP-000001
    profile_version: 1.0.0
    provider_request_id: controlled-reference

  prompt_profiles:
    - PP-PRP-000001@1.0.0
    - PP-PRP-000101@2.0.0

  context:
    context_id: PP-CTX-000001
    context_digest: sha256:...

  parameters:
    temperature: 0
    seed: 42

  started_at: 2026-08-04T20:30:00Z
  completed_at: 2026-08-04T20:30:05Z

  output:
    output_id: pp-ai-output-000001
    output_digest: sha256:...
    schema_validation: passed

  provenance: {}

31.1. Required Inference Fields​

Every material Inference Record SHALL preserve:

  • Inference identity;
  • Task;
  • Model Profile;
  • model version;
  • provider request reference where available;
  • Prompt Profiles;
  • Context Package;
  • context digest;
  • parameters;
  • random seed where available;
  • tools;
  • start and completion times;
  • output;
  • output digest;
  • token or usage metadata where lawful;
  • safety and policy results;
  • provenance.

31.2. Determinism​

A deterministic configuration SHOULD preserve seed and parameters.

Model outputs SHALL not be assumed reproducible merely because temperature is zero.

31.3. Streaming Output​

Streaming SHALL preserve the final governed output and any material moderation or interruption event.

31.4. Failed Inference​

A failed or partial inference SHALL preserve:

  • failure class;
  • partial output;
  • exposure risk;
  • retry;
  • fallback;
  • provenance.

31.5. Retry​

A retry SHALL create a new Inference Record.

32. Structured Output​

Machine-actionable AI output SHALL conform to an approved schema.

32.1. Output Contract​

The output contract SHALL identify:

  • schema;
  • schema version;
  • required fields;
  • prohibited fields;
  • value constraints;
  • citation requirements;
  • uncertainty requirements;
  • validation;
  • repair policy.

32.2. Schema Validation​

Schema validation SHALL occur before output is admitted to downstream processing.

32.3. Repair​

Automatic output repair SHALL preserve:

  • original output;
  • repair method;
  • repair model or Rule;
  • repaired output;
  • differences;
  • validation;
  • provenance.

Repair SHALL not invent missing evidence or authority.

32.4. Free-Text Output​

Free-text outputs used for high-impact purposes SHALL be reviewed and, where possible, converted to governed structured objects.

32.5. Hidden Fields​

Model output SHALL not be trusted to preserve secret or policy fields unless enforced outside the model.

33. Tool Governance​

AI tools SHALL be governed independently from model prompts.

Every tool SHALL identify:

  • Tool identity;
  • version;
  • owning Component;
  • purpose;
  • input schema;
  • output schema;
  • permission requirements;
  • tenant behaviour;
  • rights behaviour;
  • side effects;
  • confirmation requirements;
  • logging;
  • security classification;
  • provenance.

33.1. Tool Classes​

Tools MAY include:

  • retrieval read;
  • graph read;
  • Registry read;
  • schema validation;
  • calculation;
  • source fetch;
  • citation creation;
  • Candidate drafting;
  • issue creation;
  • file generation;
  • write action;
  • activation action.

33.2. Read Versus Write​

Read and write permissions SHALL remain separate.

33.3. Side-Effecting Tools​

Side-effecting tools SHALL require explicit authorisation appropriate to the action.

33.4. Runtime and Activation Tools​

AI models SHALL not receive direct activation authority.

33.5. Tool Output Trust​

Tool output SHALL preserve source, schema, time, rights and trust classification.

34. Tool Invocation Record​

Every material tool call SHALL create a Tool Invocation Record.

tool_invocation:
  invocation_id: PP-TIR-000001
  inference_id: PP-AIR-000001

  tool:
    tool_id: tool.pergamum.graph-read
    version: 2.0.0

  input_digest: sha256:...
  authorised_scope:
    tenant_scope:
      mode: none

  started_at: 2026-08-04T20:30:01Z
  completed_at: 2026-08-04T20:30:02Z
  status: succeeded

  output_digest: sha256:...
  provenance: {}

34.1. Required Invocation Fields​

Every material invocation SHALL preserve:

  • invocation identity;
  • inference;
  • tool;
  • tool version;
  • authorised scope;
  • input;
  • input digest;
  • output;
  • output digest;
  • start and completion;
  • status;
  • side effects;
  • confirmation;
  • provenance.

34.2. Tool Failure​

Tool failure SHALL not be silently converted into model certainty.

34.3. Tool Injection​

Tool-returned content SHALL be treated as data unless the tool is explicitly authorised to return governed instructions.

34.4. Write Receipt​

A write tool SHALL return a verifiable receipt.

35. Grounding​

Every material source-derived output claim SHALL be grounded in retrieved evidence.

35.1. Grounding Record​

grounding_record:
  grounding_id: PP-GRD-000001
  inference_id: PP-AIR-000001

  output_claim:
    claim_id: claim-001
    text_digest: sha256:...

  supporting_results:
    - PP-RRS-000001
    - PP-RRS-000002

  supporting_objects:
    - PP-SF-000101
    - PP-KA-000201

  support_state: supported_with_conditions
  limitations:
    - firmware_scope_limited

  provenance: {}

35.2. Grounding States​

States MAY include:

  • directly supported;
  • supported;
  • supported with conditions;
  • partially supported;
  • inferred;
  • unsupported;
  • contradicted;
  • unable to determine.

35.3. Claim Granularity​

Grounding SHOULD occur at claim or sentence level for high-impact outputs.

35.4. Multi-Claim Paragraphs​

A paragraph containing several claims SHOULD preserve separate evidence relationships.

35.5. Unsupported Claims​

Unsupported source-derived claims SHALL be:

  • removed;
  • qualified;
  • marked as inference;
  • sent for review;
  • or blocked

according to task risk.

35.6. Contradicted Claims​

A contradicted claim SHALL not be presented as settled fact without explicit conflict treatment.

36. Citation Generation​

AI outputs using source-derived knowledge SHALL produce governed citations where required.

Citations SHALL preserve:

  • Citation Object;
  • source object;
  • source version;
  • Source Fragment;
  • exact locator;
  • official or controlled source link;
  • Rights Record;
  • attribution;
  • access time where relevant;
  • claim relationship;
  • provenance.

36.1. Citation Non-Fabrication​

The model SHALL not invent:

  • source identifiers;
  • URLs;
  • clauses;
  • page numbers;
  • quotations;
  • licences;
  • authors;
  • dates.

36.2. Citation Validation​

Citation targets SHALL be validated against retrieved and eligible objects.

36.3. Quotation​

Verbatim quotation SHALL pass rights and quotation-limit controls.

36.4. Paraphrase​

Paraphrase SHALL not be represented as quotation.

36.5. Citation Coverage​

Evaluation SHOULD measure the proportion of material source-derived claims with valid citations.

37. Output Classification​

Every AI output SHALL be classified.

Classes MAY include:

  • retrieval result;
  • source extract;
  • governed summary candidate;
  • assertion candidate;
  • relationship candidate;
  • mapping candidate;
  • Change Candidate draft;
  • analysis;
  • inference;
  • recommendation;
  • translation;
  • report draft;
  • Publication draft;
  • code or schema draft;
  • validation explanation.

37.1. Candidate Labelling​

AI-generated candidates SHALL be clearly labelled as candidates.

37.2. Source-Derived Versus Inferred​

Outputs SHALL distinguish:

  • direct source content;
  • structured extraction;
  • governed knowledge;
  • model inference;
  • architectural recommendation;
  • unresolved uncertainty.

37.3. Public Output​

Public output SHALL require Publication governance and rights clearance.

37.4. Runtime Output​

An AI output SHALL not be treated as Runtime configuration without PP-CCPS governance.

38. Human Review​

Review requirements SHALL be risk-based.

38.1. Mandatory Review​

Mandatory review SHALL apply to outputs concerning:

  • legal obligations;
  • regulatory applicability;
  • rights and licensing;
  • certification;
  • safety;
  • formulas;
  • emission factors;
  • financial impact;
  • tenant access controls;
  • public claims;
  • Change Decisions;
  • Runtime activation.

38.2. Reviewer Competence​

The reviewer SHALL possess competence appropriate to the output.

38.3. Review Record​

Review SHALL preserve:

  • output;
  • Inference Record;
  • Context Package;
  • citations;
  • reviewer;
  • competence;
  • Findings;
  • corrections;
  • Decision;
  • time;
  • provenance.

38.4. Review Expiration​

Review MAY expire after source, model, prompt, rights, applicability or policy change.

39. External Provider Governance​

Before content is sent to an external AI or embedding provider, the system SHALL verify:

  • contractual permission;
  • source rights;
  • tenant permission;
  • white-label permission;
  • confidentiality;
  • personal-data basis;
  • region and data residency;
  • retention;
  • logging;
  • provider training use;
  • subprocessors;
  • security;
  • incident notification;
  • deletion;
  • audit rights.

39.1. Provider Training​

Provider training use SHALL default to prohibited for Pergamum Pulse source content unless explicit permission exists.

39.2. Provider Retention​

Retention SHALL be explicitly documented.

39.3. Zero-Retention Claims​

Zero-retention configuration SHALL be supported by contract or provider control evidence where relied upon.

39.4. Provider Change​

A provider or deployment change SHALL trigger Profile, rights, security and evaluation review.

39.5. Cross-Border Processing​

Cross-border processing SHALL be evaluated by jurisdiction and contract.

40. Tenant and White-Label Isolation​

Isolation SHALL apply before and during:

  • chunking;
  • embedding;
  • index storage;
  • query embedding;
  • retrieval;
  • reranking;
  • context assembly;
  • model processing;
  • tool use;
  • caching;
  • evaluation;
  • logging;
  • output;
  • deletion.

40.1. Tenant Context​

Every Request, Plan, Session, Context Package, Task and Inference SHALL preserve tenant context.

40.2. White-Label Context​

White-label operator identity and overlay policy SHALL remain explicit.

40.3. Cross-Tenant Retrieval​

Cross-tenant retrieval SHALL be prohibited unless a governed, lawful, purpose-specific aggregation or promotion path authorises it.

40.4. Global Knowledge​

Global canonical knowledge SHALL remain distinguishable from tenant-derived knowledge.

40.5. Tenant Promotion​

Tenant-derived knowledge SHALL not enter global indexes until rights, confidentiality, semantic, conflict and governance review is complete.

40.6. Cache Isolation​

Caches SHALL be tenant- and scope-aware.

41. Retrieval and Model Caches​

Caches MAY include:

  • query-result cache;
  • embedding cache;
  • reranking cache;
  • Context Package cache;
  • model-response cache;
  • tool-output cache.

41.1. Cache Key​

Cache keys SHALL include all material policy inputs, including:

  • tenant;
  • white-label operator;
  • rights state;
  • purpose;
  • valid time;
  • index version;
  • model version;
  • Prompt Profile;
  • filters;
  • security classification.

41.2. Cache Leakage​

A cache SHALL not return content from a broader scope than the current Request permits.

41.3. Cache Expiration​

Expiration SHALL consider:

  • source freshness;
  • rights expiry;
  • model change;
  • prompt change;
  • index rebuild;
  • tenant change;
  • deletion;
  • revocation.

41.4. Cache Provenance​

A cached result SHALL remain traceable to the original execution.

42. Security Classification​

Retrieval and processing objects SHALL inherit or derive classification.

Classes MAY include:

  • Public;
  • Internal;
  • Confidential;
  • Restricted;
  • Tenant Confidential;
  • White-label Confidential;
  • Legal Privilege;
  • Trade Secret;
  • Security Sensitive;
  • Personal Data;
  • Copyright Restricted.

Classification SHALL govern:

  • index placement;
  • encryption;
  • requester eligibility;
  • model eligibility;
  • tool eligibility;
  • logging;
  • export;
  • retention;
  • deletion;
  • Publication.

43. Data Minimisation​

Only data necessary for the declared purpose SHALL be:

  • indexed;
  • retrieved;
  • included in context;
  • sent to a model;
  • logged;
  • retained.

43.1. Sensitive Fields​

Sensitive fields SHOULD be:

  • excluded;
  • tokenised;
  • pseudonymised;
  • encrypted;
  • redacted;
  • or referenced indirectly

where the task permits.

43.2. Full Document Use​

Full-document model processing SHALL require justification where targeted chunks are sufficient.

43.3. Output Minimisation​

Outputs SHALL not reproduce more restricted source content than necessary.

44. Personal Data​

Personal data processing SHALL preserve:

  • lawful basis;
  • purpose;
  • data-subject category;
  • data category;
  • minimisation;
  • retention;
  • rights handling;
  • tenant scope;
  • region;
  • provider;
  • security;
  • provenance.

44.1. Special Categories​

Special-category or highly sensitive personal data SHALL require enhanced controls.

44.2. Model Memorisation Risk​

Tasks involving personal data SHALL assess memorisation, leakage and provider-training risks.

44.3. Data Subject Requests​

Deletion or access requests SHALL propagate through retrieval artefacts where required.

45. Prompt and Context Exfiltration Defence​

The system SHALL prevent unauthorised disclosure of:

  • system prompts;
  • Prompt Profiles;
  • hidden policies;
  • restricted Context Packages;
  • source content;
  • tenant data;
  • secrets;
  • tool credentials;
  • internal identifiers where sensitive.

45.1. Output Filtering​

Outputs SHOULD be checked for:

  • restricted source reproduction;
  • secret leakage;
  • personal data;
  • cross-tenant data;
  • hidden prompt disclosure;
  • unsafe tool instructions;
  • prohibited quotations.

45.2. Canary and Detection Controls​

Security-sensitive deployments MAY use canary values or detection controls.

45.3. Refusal and Redaction​

The model or orchestration layer SHALL refuse or redact where policy requires.

45.4. Logging​

Security logs SHALL not create a secondary leakage path.

46. Retrieval Evaluation​

Retrieval systems SHALL be evaluated for their declared tasks and scopes.

46.1. Evaluation Dimensions​

Dimensions MAY include:

  • recall;
  • precision;
  • citation coverage;
  • authority coverage;
  • conflict coverage;
  • source diversity;
  • temporal correctness;
  • tenant isolation;
  • rights compliance;
  • latency;
  • completeness;
  • ranking stability;
  • robustness;
  • abstention quality.

46.2. Evaluation Dataset​

Every evaluation dataset SHALL identify:

  • dataset identity;
  • version;
  • source;
  • rights;
  • tenant scope;
  • expected answers or relevance judgements;
  • reviewer competence;
  • limitations;
  • provenance.

46.3. Golden Set​

A Golden Set SHOULD preserve:

  • query;
  • purpose;
  • expected eligible objects;
  • expected prohibited objects;
  • expected ranking considerations;
  • temporal context;
  • authority context;
  • tenant context.

46.4. Retrieval Recall​

Recall SHALL be measured against eligible relevant content, not all stored content.

46.5. Restricted Content​

Evaluation SHALL verify that prohibited content is not returned or sent to a model.

46.6. Conflict Recall​

Tasks requiring balanced analysis SHOULD evaluate whether material competing assertions are retrieved.

46.7. Identifier Recall​

Exact governed identifier queries SHOULD be separately evaluated.

47. AI Output Evaluation​

AI outputs SHALL be evaluated according to task risk.

47.1. Evaluation Dimensions​

Dimensions MAY include:

  • grounding;
  • factual support;
  • citation validity;
  • citation coverage;
  • source fidelity;
  • authority disclosure;
  • uncertainty disclosure;
  • completeness;
  • semantic accuracy;
  • schema validity;
  • rights compliance;
  • tenant isolation;
  • refusal quality;
  • tool-use correctness;
  • prompt-injection resistance;
  • harmful leakage;
  • reproducibility.

47.2. Evaluation Record​

ai_evaluation:
  evaluation_id: PP-AEV-000001
  target:
    inference_id: PP-AIR-000001

  evaluation_profile: pp.eval.assertion-candidate
  evaluation_profile_version: 1.0.0

  dimensions:
    grounding: passed
    citation_validity: passed
    schema_validity: passed
    unsupported_claim_rate: 0.0

  evaluator:
    type: human_and_deterministic
    reviewer_id: actor.example

  status: passed
  provenance: {}

47.3. Automated Evaluation​

Automated evaluators SHALL identify:

  • evaluator model or Rule;
  • version;
  • calibration;
  • known limitations;
  • independence from target model where relevant;
  • provenance.

47.4. Model-as-Judge​

Model-as-judge output SHALL not be treated as definitive without task-appropriate validation.

47.5. Human Evaluation​

High-impact evaluations SHOULD include competent human review.

47.6. Regression Gate​

A model, prompt, retrieval or index change SHALL pass defined regression criteria before production use.

48. Adversarial Evaluation​

Adversarial evaluation SHOULD cover:

  • direct prompt injection;
  • indirect prompt injection;
  • malicious metadata;
  • tool-output injection;
  • cross-tenant query attempts;
  • rights-bypass attempts;
  • source-citation fabrication;
  • system-prompt extraction;
  • restricted quotation requests;
  • conflicting-source manipulation;
  • poisoned embeddings;
  • malicious documents;
  • index contamination;
  • data exfiltration;
  • tool misuse;
  • privilege escalation;
  • refusal bypass.

48.1. Poisoned Knowledge​

Suspected poisoned content SHALL be quarantined and excluded from trusted retrieval.

48.2. Evaluation Isolation​

Adversarial tests SHALL not expose real restricted content unnecessarily.

48.3. Findings​

Material findings SHALL trigger remediation, retesting and Incident treatment where appropriate.

49. Model and Prompt Drift​

Drift MAY arise from:

  • model version change;
  • provider-side model change;
  • Prompt Profile change;
  • tool change;
  • context-window change;
  • safety-policy change;
  • tokenizer change;
  • routing change;
  • parameter change.

49.1. Drift Detection​

Drift detection SHALL compare:

  • evaluation metrics;
  • output distributions;
  • citation behaviour;
  • refusal behaviour;
  • tool-use behaviour;
  • latency;
  • cost;
  • rights or leakage incidents;
  • tenant-isolation results.

49.2. Material Drift​

Material drift SHALL trigger:

  • Profile review;
  • evaluation;
  • risk review;
  • affected-task analysis;
  • rollback or suspension where required;
  • provenance.

49.3. Undisclosed Provider Drift​

Where exact provider changes are undisclosed, the system SHALL use observed-behaviour monitoring and disclose historical-replay limitations.

50. Embedding and Index Drift​

Embedding drift MAY arise from:

  • model change;
  • preprocessing change;
  • tokenizer change;
  • chunking change;
  • metadata augmentation change;
  • language-detection change;
  • rights filtering change.

Index drift MAY arise from:

  • content additions;
  • deletions;
  • stale records;
  • failed builds;
  • ranking configuration changes;
  • graph relationship changes;
  • tenant-scope errors.

50.1. Re-Embedding Trigger​

Re-embedding MAY be required where:

  • source content changes;
  • model version changes;
  • dimensions change;
  • Profile changes;
  • rights change;
  • security classification changes;
  • retrieval quality materially degrades.

50.2. Mixed Embedding Spaces​

Vectors from incompatible embedding spaces SHALL not be compared in one index without an approved compatibility method.

50.3. Parallel Index Migration​

A model migration SHOULD support parallel indexes, evaluation, controlled cutover and rollback.

50.4. Stale Embedding​

A stale embedding SHALL not be silently treated as current.

50.5. Index Drift Finding​

Index incompleteness, stale vectors or scope leakage SHALL create Findings and potentially Incidents.

51. Rights Expiration and Revocation​

Rights expiration or revocation SHALL trigger an affected-object analysis across:

  • source content;
  • chunks;
  • embeddings;
  • lexical indexes;
  • vector indexes;
  • graph indexes;
  • caches;
  • Context Packages;
  • prompt examples;
  • evaluation datasets;
  • Inference Records;
  • generated summaries;
  • assertions;
  • mappings;
  • Change Candidates;
  • Publications.

51.1. Future Use​

Future retrieval or processing SHALL be blocked where rights no longer permit it.

51.2. Historical Records​

Historical records MAY be retained only where lawful, contractually permitted or required by Legal Hold.

51.3. Public Outputs​

Public outputs affected by revoked rights SHALL follow correction or withdrawal processes.

51.4. Model Training​

Where source content entered fine-tuning or model training, the rights response SHALL assess deletion, unlearning, retraining and residual risk.

52. Deletion Propagation​

Every material deletion SHALL create a Deletion Propagation Record.

deletion_propagation:
  deletion_id: PP-DPR-000001
  source_object: PP-SRC-000001
  legal_or_contractual_basis: rights_revoked

  affected_objects:
    chunks:
      - PP-CHK-000001
    embeddings:
      - PP-EMB-000001
    indexes:
      - PP-IDX-000201
    caches: []
    context_packages:
      - PP-CTX-000001

  required_actions:
    - remove_active_vector
    - invalidate_cache
    - restrict_historical_access

  status: in_progress
  provenance: {}

52.1. Propagation Scope​

Deletion analysis SHALL include:

  • primary storage;
  • replicas;
  • indexes;
  • embeddings;
  • caches;
  • logs;
  • backups;
  • evaluation datasets;
  • prompt examples;
  • model-training datasets;
  • fine-tuned models;
  • exports;
  • Publications;
  • historical archives.

52.2. Tombstones​

Tombstones SHOULD prevent deleted objects from being silently reintroduced during rebuild.

52.3. Deletion Verification​

Deletion SHALL produce verifiable completion or exception receipts.

52.4. Backup Treatment​

Backup deletion or expiry SHALL follow retention, security and Legal Hold policy.

52.5. Rebuild​

Index rebuild SHALL exclude deleted or revoked objects.

53. Model Unlearning and Retraining​

Where content was used for model training and removal is required, the system SHALL record:

  • affected model;
  • model version;
  • training dataset;
  • affected records;
  • legal or contractual requirement;
  • technical feasibility;
  • unlearning method;
  • retraining method;
  • evaluation;
  • residual risk;
  • Decision;
  • provenance.

53.1. Inability to Unlearn​

Where reliable unlearning is not feasible, the system SHALL consider:

  • model retirement;
  • full retraining;
  • access restriction;
  • compensating controls;
  • disclosure;
  • contractual remediation.

53.2. Evaluation​

Unlearning or retraining SHALL be evaluated for both removal effectiveness and retained model quality.

54. Source Withdrawal and Staleness​

Source withdrawal or supersession SHALL trigger:

  • chunk status review;
  • embedding status review;
  • index update;
  • cache invalidation;
  • Context Package impact analysis;
  • output impact analysis;
  • assertion review;
  • mapping review;
  • Publication review.

54.1. Historically Valid Knowledge​

Historically valid content MAY remain available through historical retrieval where rights permit.

54.2. Current Retrieval​

Current retrieval SHALL not silently return withdrawn content as current.

54.3. Superseded Content​

Superseded content MAY be returned where:

  • historical comparison is requested;
  • a conflict requires it;
  • the Plan explicitly includes it;
  • status is clearly disclosed.

55. Retrieval and AI Incidents​

Incidents MAY include:

  • cross-tenant retrieval;
  • white-label leakage;
  • restricted source exposure;
  • rights-bypass retrieval;
  • prompt injection;
  • data exfiltration;
  • fabricated citation;
  • poisoned index;
  • embedding contamination;
  • stale-index use;
  • unauthorised external processing;
  • provider retention breach;
  • model-training misuse;
  • tool privilege escalation;
  • deletion-propagation failure;
  • hidden-prompt disclosure;
  • unsupported high-impact output;
  • incorrect activation based on AI output.

Every Incident SHALL identify:

  • Incident Identifier;
  • detection;
  • severity;
  • affected source objects;
  • affected chunks;
  • affected embeddings;
  • affected indexes;
  • affected Retrieval Sessions;
  • affected Context Packages;
  • affected Inference Records;
  • affected tenants;
  • affected white-label operators;
  • containment;
  • correction;
  • notification;
  • deletion;
  • rollback;
  • root cause;
  • remediation;
  • provenance.

55.1. Incident Severity​

Severity MAY be:

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

55.2. Evidence Preservation​

Incident response SHALL preserve evidence and chain of custody.

56. Logging and Observability​

Observability SHALL cover:

  • eligibility decisions;
  • chunking;
  • embedding;
  • index builds;
  • retrieval Requests;
  • Plans;
  • Sessions;
  • filter decisions;
  • ranking;
  • Context Packages;
  • model execution;
  • tool calls;
  • grounding;
  • citations;
  • review;
  • deletion;
  • Incidents.

56.1. Sensitive Logging​

Logs SHALL minimise:

  • source content;
  • personal data;
  • tenant data;
  • secrets;
  • restricted prompts;
  • model outputs containing protected content.

56.2. Correlation​

Material objects SHOULD share trace or correlation identifiers.

56.3. Tamper Evidence​

High-impact audit logs SHOULD be tamper-evident.

56.4. Retention​

Log retention SHALL be purpose-, rights-, privacy- and security-aware.

57. Availability and Resilience​

Retrieval and AI processing SHALL define:

  • availability objectives;
  • degraded modes;
  • fallback;
  • index recovery;
  • vector-store recovery;
  • graph recovery;
  • cache recovery;
  • provider outage treatment;
  • model outage treatment;
  • disaster recovery;
  • integrity validation.

57.1. Degraded Retrieval​

Degraded mode SHALL not weaken rights, tenant or security filters.

57.2. Provider Fallback​

Fallback models or providers SHALL be pre-approved through Model Profiles.

57.3. Recovery Integrity​

Recovery SHALL validate:

  • object identities;
  • chunk digests;
  • embedding lineage;
  • index membership;
  • rights;
  • tenant scope;
  • historical state;
  • provenance.

57.4. Offline Mode​

An offline mode MAY use approved local indexes and models with explicit freshness limitations.

58. Cost and Performance Governance​

Performance optimisation SHALL not bypass governance.

Metrics MAY include:

  • retrieval latency;
  • reranking latency;
  • context size;
  • model latency;
  • token usage;
  • embedding cost;
  • index size;
  • cache hit rate;
  • evaluation cost;
  • tenant allocation.

58.1. Cost Allocation​

Cost records SHOULD preserve tenant, white-label, task and Component lineage where commercially relevant.

58.2. Token Reduction​

Token reduction SHALL not remove material conditions, exceptions, citations or conflict evidence.

58.3. Latency Fallback​

Latency fallback SHALL not broaden scope or use a less secure provider without approval.

59. Module and Component Lineage​

Every material retrieval and AI path SHALL preserve:

  • accountable Module;
  • source-owning Component;
  • Rights Registry Component;
  • chunking Component;
  • embedding Component;
  • lexical-index Component;
  • vector-index Component;
  • graph Component;
  • retrieval-orchestration Component;
  • reranking Component;
  • Context Assembly Component;
  • Prompt Registry Component;
  • Model Registry Component;
  • Agent Component;
  • tool-owning Components;
  • evaluation Component;
  • HECATE;
  • Publication-consuming Components;
  • Change Intelligence Components;
  • Runtime-consuming Components;
  • archive Component;
  • tenant lineage;
  • white-label lineage.

Pergamum Pulse SHALL preserve both Module and Component lineage.

No orphan Component lineage is permitted.

60. Provenance​

End-to-end provenance SHALL connect:

  • Source Object;
  • Source Capture;
  • Rights Record;
  • Knowledge Document;
  • Knowledge Section;
  • Source Fragment;
  • Knowledge Assertion;
  • Knowledge Entity;
  • Mapping Object;
  • Retrieval Eligibility Record;
  • Knowledge Chunk;
  • Chunking Profile;
  • Embedding Profile;
  • Embedding Record;
  • Retrieval Index;
  • Index Build Record;
  • Retrieval Request;
  • Retrieval Plan;
  • Retrieval Session;
  • Retrieval Result;
  • Reranking Record;
  • Context Package;
  • Prompt Profile;
  • Model Profile;
  • AI Processing Task;
  • AI Inference Record;
  • Tool Invocation Record;
  • Grounding Record;
  • Citation Object;
  • Review Record;
  • AI Evaluation Record;
  • Change Candidate;
  • Publication;
  • Deletion Propagation Record;
  • Incident;
  • Module lineage;
  • Component lineage;
  • tenant lineage;
  • white-label lineage;
  • valid time;
  • transaction time.

Materially incomplete provenance SHALL block:

  • high-impact AI use;
  • assertion approval;
  • mapping approval;
  • Change Candidate approval;
  • unqualified Publication;
  • certification reliance;
  • Runtime activation;
  • definitive historical claims.

61. Historical Retrieval and Processing Reconstruction​

Historical reconstruction SHALL answer:

  • which source version existed;
  • which rights applied;
  • which chunks existed;
  • which Chunking Profile was used;
  • which Embedding Profile and model were used;
  • which index version was queried;
  • which Request and Plan were executed;
  • which filters were applied;
  • which results were returned;
  • which results were excluded;
  • which Context Package was assembled;
  • which Prompt Profiles were active;
  • which Model Profile was used;
  • which tools were invoked;
  • which output was generated;
  • which citations and grounding relationships existed;
  • which reviewer approved or rejected the output;
  • which downstream objects relied on it;
  • whether deletion, withdrawal or Incident later occurred.

61.1. Exact Replay​

Exact Replay SHALL use the historical:

  • object versions;
  • Rights Records;
  • chunks;
  • indexes;
  • model versions;
  • Prompt Profiles;
  • Retrieval Plans;
  • filters;
  • parameters;
  • tools;
  • evaluation Profiles.

61.2. Exact Output Limitation​

Exact model-output reproduction MAY be impossible where providers do not guarantee deterministic or immutable models.

The limitation SHALL be disclosed.

61.3. Retrieval Replay​

Retrieval Replay SHOULD reconstruct candidate sets, filters, ranks and included Context Package objects from historical index snapshots or equivalent records.

61.4. Semantic Replay​

Semantic Replay MAY evaluate the historical Request under later approved models, indexes or interpretations.

Exact Replay and Semantic Replay SHALL remain distinct.

61.5. Non-Retroactivity​

Current rights, prompts, models, entity resolution, mappings or filters SHALL NOT be silently applied to historical executions.

62. HECATE Validation​

HECATE SHALL validate objective structure including:

  • Retrieval Eligibility Record;
  • source object and version;
  • Rights Record relationships;
  • Knowledge Chunk identity;
  • source locator;
  • chunk digest;
  • Chunking Profile;
  • Embedding Profile;
  • model version;
  • Embedding Record;
  • vector dimensions;
  • vector index relationship;
  • Retrieval Index scope;
  • Index Build Record;
  • Retrieval Request;
  • Retrieval Plan;
  • filters;
  • temporal context;
  • Retrieval Session;
  • Retrieval Results;
  • scores and rank fields;
  • Context Package;
  • token budget;
  • Prompt Profiles;
  • Model Profile;
  • AI Processing Task;
  • AI Inference Record;
  • Tool Invocation Records;
  • output schema;
  • Grounding Records;
  • Citation Objects;
  • review state;
  • evaluation state;
  • deletion state;
  • tenant scope;
  • white-label scope;
  • Module lineage;
  • Component lineage;
  • provenance.

HECATE MAY validate:

  • schema conformance;
  • object references;
  • digest consistency;
  • dimension compatibility;
  • index membership;
  • deterministic filters;
  • rights-state presence;
  • tenant isolation Rules;
  • citation-target existence;
  • grounding completeness;
  • output-schema validity;
  • deletion-propagation completeness;
  • evaluation thresholds.

HECATE SHALL NOT:

  • grant rights;
  • approve source authority;
  • invent evidence;
  • establish factual truth;
  • approve legal interpretation;
  • approve semantic equivalence;
  • approve a Change Candidate;
  • approve public Publication;
  • create certification status;
  • activate Runtime state;
  • treat a retrieval score as proof;
  • treat a model evaluation score as authority.

63. Profile Operating Modes​

Implementations MAY define operating modes.

63.1. Public Knowledge Mode​

Public Knowledge Mode SHALL allow only content approved for public processing and output.

63.2. Viroway Internal Mode​

Internal Mode MAY include confidential Viroway knowledge subject to Role and purpose controls.

63.3. Tenant-Isolated Mode​

Tenant-Isolated Mode SHALL enforce tenant-specific storage, retrieval, model and cache boundaries.

63.4. White-Label-Isolated Mode​

White-Label-Isolated Mode SHALL preserve operator-specific knowledge and configuration.

63.5. Regulated Review Mode​

Regulated Review Mode SHOULD require:

  • authoritative-source preference;
  • complete citations;
  • conflict visibility;
  • competent review;
  • immutable audit records;
  • restricted model and tool selection.

63.6. Historical Research Mode​

Historical Mode SHALL preserve historical time and SHALL clearly distinguish superseded or withdrawn content.

63.7. High-Security Mode​

High-Security Mode MAY require:

  • local models;
  • local embeddings;
  • physical index separation;
  • confidential computing;
  • no content logging;
  • restricted tools;
  • mandatory review;
  • enhanced monitoring.

64. Conformance Levels​

64.1. Level 1 — Traceable Retrieval​

The implementation has:

  • stable chunk identities;
  • source lineage;
  • governed indexes;
  • Retrieval Requests;
  • Retrieval Plans;
  • Retrieval Sessions;
  • basic rights and tenant filters;
  • provenance.

64.2. Level 2 — Governed Embedding and Context​

It additionally has:

  • Embedding Profiles;
  • Embedding Records;
  • vector-store isolation;
  • Context Packages;
  • Prompt Profiles;
  • Model Profiles;
  • model-processing eligibility;
  • deletion propagation;
  • review.

64.3. Level 3 — Grounded AI Processing​

It additionally has:

  • AI Processing Tasks;
  • Inference Records;
  • Tool Invocation Records;
  • claim-level grounding;
  • validated citations;
  • structured output;
  • evaluation;
  • prompt-injection defence;
  • Module and Component lineage.

64.4. Level 4 — Historically Assured and Automation-Eligible​

It additionally has:

  • immutable historical records;
  • exact input and context digests;
  • pinned or disclosed model versions;
  • regression gates;
  • adversarial evaluation;
  • rights-revocation propagation;
  • deletion verification;
  • Exact Replay or documented limitations;
  • HECATE validation;
  • no blocking Findings;
  • complete provenance.

Level 4 SHALL NOT imply authority to publish, approve or activate.

65. Conformance Fixtures​

Implementations SHOULD provide fixtures for:

  • eligible public Knowledge Document;
  • restricted Knowledge Document;
  • metadata-indexing-only source;
  • no-embedding source;
  • no-external-processing source;
  • expired eligibility;
  • valid structure-aware chunk;
  • chunk without source locator;
  • chunk with lost heading lineage;
  • chunk splitting a formula incorrectly;
  • chunk preserving a table;
  • redacted chunk;
  • fragment-level rights override;
  • deterministic Chunking Profile;
  • semantic Chunking Profile with model provenance;
  • valid Embedding Profile;
  • mutable unpinned embedding model;
  • valid Embedding Record;
  • stale Embedding Record;
  • embedding with wrong dimensions;
  • embedding without Rights Record;
  • tenant-isolated vector index;
  • prohibited mixed-tenant vector index;
  • complete Index Build Record;
  • incremental index build;
  • failed index records;
  • incomplete index build;
  • exact identifier lexical retrieval;
  • fuzzy retrieval without entity merge;
  • vector retrieval with declared metric;
  • vector threshold without evaluation;
  • graph retrieval with explainable path;
  • historical graph retrieval;
  • hybrid reciprocal-rank fusion;
  • valid Retrieval Request;
  • Request without purpose;
  • Request containing confidential query data;
  • valid Retrieval Plan;
  • Plan fallback that preserves rights;
  • Plan fallback that broadens tenant scope;
  • pre-ranking rights filter;
  • post-filter exposure defect;
  • valid ranking record;
  • authority-weighted ranking with conflict preservation;
  • reranker using prohibited external provider;
  • deduplication preserving source diversity;
  • valid Retrieval Session;
  • partial Session failure;
  • valid Retrieval Result;
  • result with incomparable scores collapsed;
  • result snippet without source offsets;
  • valid Context Package;
  • Context Package with token overflow;
  • Context Package omitting a known conflict;
  • governed context compression;
  • AI summary incorrectly replacing source evidence;
  • valid Prompt Profile;
  • Prompt Profile containing a secret;
  • retrieved prompt injection;
  • indirect tool-output injection;
  • valid Model Profile;
  • unapproved model substitution;
  • external model with provider training enabled;
  • valid AI Processing Task;
  • high-impact Task without review;
  • valid Inference Record;
  • retry represented as separate Inference;
  • partial inference failure;
  • valid structured output;
  • output repair preserving original;
  • output repair inventing evidence;
  • governed read tool;
  • side-effecting tool without approval;
  • valid Tool Invocation Record;
  • tool-output injection;
  • directly supported claim;
  • partially supported claim;
  • unsupported claim;
  • contradicted claim;
  • valid source citation;
  • fabricated citation;
  • quotation exceeding Rights Record;
  • assertion-candidate output;
  • public-output draft without Publication approval;
  • tenant-isolated Context Package;
  • cross-tenant cache leakage;
  • cache key missing Rights Record state;
  • personal-data minimisation;
  • full-document processing without justification;
  • system-prompt extraction attempt;
  • restricted-source exfiltration attempt;
  • retrieval Golden Set;
  • conflict-recall evaluation;
  • valid AI Evaluation Record;
  • model-as-judge without limitation disclosure;
  • regression failure;
  • adversarial prompt-injection test;
  • poisoned source quarantine;
  • model drift;
  • prompt drift;
  • embedding drift;
  • mixed incompatible embedding spaces;
  • parallel index migration;
  • rights expiration;
  • rights revocation;
  • complete Deletion Propagation Record;
  • incomplete vector deletion;
  • backup deletion exception;
  • model-unlearning requirement;
  • inability-to-unlearn treatment;
  • withdrawn source excluded from current retrieval;
  • superseded source included in Historical Mode;
  • Retrieval Incident;
  • tamper-evident logging;
  • degraded retrieval preserving security;
  • unapproved provider fallback;
  • recovery integrity validation;
  • complete Module lineage;
  • complete Component lineage;
  • materially incomplete provenance;
  • Exact Retrieval Replay;
  • Exact Inference Replay with provider limitation;
  • Semantic Replay;
  • HECATE structural receipt;
  • HECATE attempting authority creation;
  • complete Level 4 conformance record.

66. Migration and Compatibility​

Profile revisions SHALL identify:

  • source Profile version;
  • target Profile version;
  • changed chunk fields;
  • changed Chunking Profiles;
  • changed Embedding Profiles;
  • changed model Profiles;
  • changed index schemas;
  • changed Retrieval Plans;
  • changed Prompt Profiles;
  • changed grounding requirements;
  • changed evaluation thresholds;
  • migration Rules;
  • compatibility;
  • affected chunks;
  • affected embeddings;
  • affected indexes;
  • affected caches;
  • affected Context Packages;
  • affected outputs;
  • validation;
  • provenance.

Migration SHALL NOT:

  • reuse object identifiers;
  • overwrite historical versions;
  • infer missing rights;
  • widen tenant scope;
  • convert unknown eligibility to permitted;
  • compare incompatible embedding spaces without an approved method;
  • conceal stale vectors;
  • discard deletion tombstones;
  • overwrite original model output;
  • treat a new model as historically identical;
  • activate downstream change.

66.1. Re-Chunking Migration​

Re-chunking SHALL preserve relationships from old chunks to new chunks where feasible.

66.2. Re-Embedding Migration​

Re-embedding SHALL preserve old Embedding Records for historical replay where lawful.

66.3. Index Migration​

Index migration SHALL include completeness, isolation, quality and rollback validation.

66.4. Prompt Migration​

Prompt migration SHALL trigger task-appropriate regression evaluation.

67. Assurance and Audit​

Assurance MAY evaluate:

  • eligibility controls;
  • chunk lineage;
  • embedding lineage;
  • index scope;
  • tenant isolation;
  • rights enforcement;
  • retrieval quality;
  • conflict coverage;
  • Context Package integrity;
  • model eligibility;
  • Prompt Profile governance;
  • tool permissions;
  • grounding;
  • citations;
  • review;
  • external-provider controls;
  • prompt-injection defence;
  • deletion propagation;
  • historical replay.

An audit record SHALL identify:

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

Audit Findings MAY include:

  • source without eligibility;
  • chunk without exact lineage;
  • embedding without rights;
  • stale vector;
  • cross-tenant index;
  • missing filter;
  • invalid cache key;
  • unauthorised external provider;
  • fabricated citation;
  • unsupported claim;
  • prompt-injection vulnerability;
  • tool privilege escalation;
  • incomplete deletion;
  • incomplete provenance;
  • failed historical reconstruction.

68. Conformance Requirements​

An implementation conforms to this Profile where it:

  1. evaluates retrieval eligibility before chunking, indexing, embedding, retrieval or model processing;
  2. preserves explicit eligibility outcomes and conditions;
  3. re-evaluates eligibility after rights, source, tenant, provider or purpose change;
  4. assigns stable PP-CHK- identifiers to chunks;
  5. links every chunk to exact source object, version, section or fragment and locator;
  6. preserves chunk content digests;
  7. preserves chunk rights, security and tenant scope;
  8. prevents chunks from being treated as complete or authoritative sources;
  9. governs chunking through versioned Chunking Profiles;
  10. preserves headings, lists, tables, formulas, footnotes, conditions and citations where material;
  11. represents overlap explicitly;
  12. identifies context dependencies and partial structures;
  13. produces deterministic chunking where feasible;
  14. records model provenance for semantic chunking;
  15. prevents chunking from removing rights or attribution;
  16. applies fragment-level rights restrictions;
  17. governs embeddings through versioned Embedding Profiles;
  18. pins embedding model versions where available;
  19. records preprocessing, truncation, language and metadata augmentation;
  20. prevents sensitive metadata from entering embedding input without authority;
  21. treats embeddings as potentially information-bearing;
  22. assigns stable PP-EMB- identities;
  23. preserves source chunk, Profile, model, dimensions, storage, rights and provenance for every embedding;
  24. versions embeddings after source, model, Profile, rights or scope change;
  25. preserves embedding lifecycle and deletion state;
  26. represents Retrieval Indexes as governed objects;
  27. preserves index type, scope, rights, tenant boundaries, versions and build lineage;
  28. applies physical or cryptographic isolation where logical filtering is insufficient;
  29. prevents index presence or rank from creating authority;
  30. records deterministic Index Build Records;
  31. preserves incremental additions, changes and deletions;
  32. prevents failed records from silently disappearing;
  33. reports index completeness and staleness;
  34. preserves exact executed lexical queries;
  35. governs synonyms and aliases;
  36. prevents fuzzy matching from automatically merging entities;
  37. records vector model, metric, thresholds, candidates and scores;
  38. prevents score comparison across incompatible spaces without calibration;
  39. treats similarity as a discovery signal rather than proof;
  40. governs approximate-nearest-neighbour configuration;
  41. governs graph retrieval by relationship type, direction, depth, time, rights and scope;
  42. exposes material graph paths;
  43. preserves conflict treatment in graph retrieval;
  44. supports historical graph retrieval;
  45. governs hybrid retrieval and fusion;
  46. records method contribution to final ranking;
  47. prevents fusion from creating authority;
  48. assigns stable Retrieval Request identities;
  49. preserves requester, purpose, scope, time and requested object classes;
  50. treats queries as potentially sensitive;
  51. prohibits unauthorised unbounded retrieval;
  52. represents Retrieval Plans as versioned governed objects;
  53. preserves indexes, methods, filters, ranking, reranking, budgets, deduplication and fallback;
  54. prevents fallback from widening rights or tenant scope;
  55. applies security, rights and tenant filters before exposure to models;
  56. preserves executed filter provenance;
  57. governs controlled redaction;
  58. records ranking and reranking transformations;
  59. prevents recency from overriding controlling historical or legal relevance without policy;
  60. prevents rerankers from receiving prohibited content;
  61. prevents rank from being represented as truth;
  62. deduplicates without erasing source, authority, jurisdiction, version or conflict diversity;
  63. records Retrieval Sessions and partial failures;
  64. enforces Session scope and retention;
  65. represents every returned item as a Retrieval Result;
  66. preserves object version, method-specific scores, filters, citation and authority metadata;
  67. preserves snippet offsets and truncation;
  68. keeps excluded results auditable without exposing them;
  69. represents Context Packages as immutable governed objects;
  70. preserves result ordering, token counts, Prompt Profiles, rights, scope and digest;
  71. discloses omitted conflicts, gaps and rights-restricted evidence where appropriate;
  72. enforces token budgets and overflow behaviour;
  73. prevents Context inclusion from creating authority;
  74. balances relevance with rights, diversity, conflict and temporal validity;
  75. governs context compression;
  76. prevents generated summaries from silently replacing source evidence in high-impact tasks;
  77. governs prompts through versioned Prompt Profiles;
  78. separates governed instructions, user input, retrieved data and tool output;
  79. prevents Prompt Profiles from containing secrets;
  80. treats retrieved instructions as untrusted data by default;
  81. enforces instruction precedence outside retrieved content;
  82. implements prompt-injection and indirect-injection defences;
  83. prevents retrieved content from altering permissions, tools, rights, scope or activation;
  84. governs models through versioned Model Profiles;
  85. records provider, deployment, region, retention, training use, capabilities and limitations;
  86. discloses mutable-provider-version limitations;
  87. governs model substitution;
  88. prevents Model Profiles from assigning legal, constitutional, certification or Runtime authority;
  89. represents AI operations as AI Processing Tasks;
  90. binds Tasks to purpose, Context Package, model, prompts, tools, output contract, rights and review;
  91. requires competent review for high-impact Tasks;
  92. records every material model execution as an AI Inference Record;
  93. preserves model, context, prompt, parameters, tools, output digest and provenance;
  94. treats retries as separate Inference Records;
  95. preserves partial and failed inference state;
  96. validates machine-actionable output against approved schemas;
  97. preserves original and repaired output;
  98. prevents automatic repair from inventing evidence or authority;
  99. governs tools independently from prompts;
  100. separates read and write permissions;
  101. requires authorisation for side-effecting tools;
  102. prevents models from receiving direct Runtime activation authority;
  103. records material tool calls as Tool Invocation Records;
  104. preserves authorised scope, input, output, side effects and receipts;
  105. treats tool-returned content as data unless explicitly governed as instruction;
  106. grounds material source-derived claims in retrieved evidence;
  107. preserves claim-level Grounding Records for high-impact outputs;
  108. distinguishes direct support, partial support, inference, contradiction and uncertainty;
  109. removes, qualifies or reviews unsupported claims according to risk;
  110. validates citations against retrieved eligible objects;
  111. prevents citation fabrication;
  112. enforces quotation and attribution rights;
  113. distinguishes quotation from paraphrase;
  114. measures citation coverage where material;
  115. classifies AI outputs and labels candidates;
  116. distinguishes source content, structured extraction, inference and recommendation;
  117. applies Publication governance to public output;
  118. prevents AI output from becoming Runtime configuration without PP-CCPS;
  119. enforces risk-based human review;
  120. preserves reviewer competence, Findings and corrections;
  121. validates external-provider rights, confidentiality, region, retention and training use;
  122. defaults provider training use to prohibited;
  123. governs provider and cross-border changes;
  124. enforces tenant and white-label isolation at every retrieval and processing stage;
  125. prevents unauthorised cross-tenant retrieval;
  126. governs tenant-derived promotion to global indexes;
  127. makes caches rights-, purpose-, tenant-, time-, index-, model- and prompt-aware;
  128. prevents cache scope leakage;
  129. propagates rights expiry, deletion and revocation to caches;
  130. enforces security classification over indexes, models, tools, logs and outputs;
  131. applies data minimisation;
  132. avoids unnecessary full-document processing;
  133. minimises restricted content reproduction in outputs;
  134. governs personal-data processing and deletion;
  135. defends against prompt, context and source exfiltration;
  136. prevents security logs from becoming leakage paths;
  137. evaluates retrieval quality using governed datasets;
  138. evaluates recall against eligible relevant content;
  139. evaluates conflict recall and exact identifier retrieval where material;
  140. evaluates AI grounding, citation, schema, rights, isolation, refusal and tool use;
  141. treats automated and model-as-judge evaluation as non-definitive;
  142. requires regression gates after material model, prompt, retrieval or index changes;
  143. performs adversarial testing for injection, exfiltration, poisoning, leakage and privilege escalation;
  144. detects model, prompt, embedding and index drift;
  145. prevents mixing incompatible embedding spaces without an approved method;
  146. supports parallel index migration and rollback;
  147. re-evaluates stale embeddings and indexes;
  148. propagates rights expiry and revocation across retrieval and AI artefacts;
  149. records deletion through Deletion Propagation Records;
  150. uses tombstones to prevent deleted-object reintroduction;
  151. verifies deletion or preserves documented exceptions;
  152. governs model unlearning and retraining where required;
  153. treats withdrawn and superseded sources according to current or historical purpose;
  154. manages Retrieval and AI Incidents;
  155. preserves Incident evidence and chain of custody;
  156. logs material lifecycle events without excessive sensitive content;
  157. supports tamper-evident audit records for high-impact use;
  158. preserves rights and security in degraded modes and provider fallback;
  159. validates recovery integrity;
  160. prevents cost or latency optimisation from weakening governance;
  161. preserves both Module and Component lineage;
  162. preserves complete end-to-end provenance;
  163. blocks high-impact use where provenance is materially incomplete;
  164. supports historical retrieval and processing reconstruction;
  165. distinguishes Exact Replay from Semantic Replay;
  166. discloses provider limitations on exact reproduction;
  167. prevents current governance from being silently applied retroactively;
  168. validates objective structure through HECATE;
  169. prevents HECATE from granting rights, truth, approval, Publication or activation;
  170. supports Public, Internal, Tenant, White-Label, Regulated, Historical and High-Security operating modes;
  171. defines four conformance levels;
  172. supports comprehensive conformance fixtures;
  173. governs Profile migration and compatibility;
  174. preserves old chunk and embedding relationships during migration where lawful;
  175. supports retrieval and AI assurance and audit;
  176. never interprets retrieval rank, similarity, model confidence or evaluator score as authority.

69. Foundational Principle​

Pergamum Pulse retrieval SHALL not be an invisible shortcut from stored text to model output.

Every stage SHALL remain governed: eligibility, chunking, embedding, indexing, retrieval, filtering, ranking, context assembly, prompting, model execution, tool use, grounding, citation, review, deletion and historical reconstruction.

A chunk is not the source. An embedding is not the text. Similarity is not identity. Rank is not truth. Retrieval is not evidence unless the returned object supports the claim. RAG is not authority. Model confidence is not verification. A generated answer is not an approved assertion. An approved assertion is not a Change Decision. A generated configuration is not active Runtime state.

Rights, confidentiality, tenant scope and provenance SHALL follow source-derived knowledge into every vector, index, cache, prompt, Context Package and output. Retrieved instructions SHALL remain untrusted data. Conflicts and uncertainty SHALL remain visible. Deleted or revoked knowledge SHALL not persist invisibly in retrieval infrastructure.

By governing retrieval, embeddings and AI processing as versioned, rights-aware, tenant-isolated, evidence-linked and historically reconstructable operations, Pergamum Pulse can use advanced AI safely while preserving constitutional authority, legal defensibility, semantic precision, operational security and stakeholder trust.



GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ