Skip to main content

Pergamum Pulse Knowledge Document and Metadata Framework

Part II — Source Acquisition, Rights and Transformation

Part II governs how Pergamum Pulse discovers, admits, acquires, authenticates, stores, transforms, cites, reviews, restricts and withdraws knowledge sources.

Part I established the knowledge plane, PP-prefixed identities, authority separation, canonical knowledge objects, tenancy, lineage and historical trust.

Part II defines:

  • source discovery and admission;
  • source classification and authenticity;
  • capture planning and chain of custody;
  • immutable source preservation;
  • copyright, licensing and publication rights;
  • quotation and citation controls;
  • processing, embedding, retrieval and training rights;
  • parsing, OCR, translation and normalisation;
  • AI-assisted extraction and review;
  • coverage, omission and confidence;
  • quarantine, withdrawal and rights change;
  • Part II provenance and conformance.

The governing principles are:

No source SHALL enter the trusted Pergamum Pulse knowledge plane without identifiable origin, acquisition history, authority classification, rights state and provenance.

Public availability SHALL NOT be interpreted as unrestricted permission to copy, transform, embed, train on, redistribute or publish a source.

Source authenticity SHALL be evaluated independently from source authority.

Every Source Capture SHALL preserve the exact bytes, digest, acquisition method, acquisition time, acquiring actor and chain of custody of the captured source.

OCR, translation, parsing and AI extraction SHALL be governed transformations, not invisible preprocessing steps.

A transformation SHALL NOT increase the authority, rights or evidentiary weight of its source.

Every published quotation, citation, reproduced table, image, diagram, data extract or transformed claim SHALL preserve a source link and the legal or contractual basis permitting publication.

Viroway-authored documents SHALL also preserve copyright ownership, authorship basis, approval, publication scope and reuse terms.

The Part II trust path is:

Source Discovery

Source Admission

Authority, Authenticity, Rights and Risk Review

Capture Plan

Immutable Source Capture and Chain of Custody

Rights Decision by Intended Use

Transformation Plan

Parsing, OCR, Translation, Normalisation and AI Extraction

Coverage, Omission, Confidence and Human Review

Canonical Knowledge Document

Eligibility for Semantic Processing

2.1. Source Discovery

Source Discovery identifies candidate knowledge sources relevant to ZAYAZ.

Discovery MAY originate from official portals, standards publishers, accreditation bodies, certification bodies, manufacturers, suppliers, scientific publishers, public datasets, APIs, repositories, monitoring feeds, contractual deliveries, tenant uploads, white-label uploads, internal Viroway authorship, EcoWorld research, authorised agents or human curators.

2.1.1. Source Candidate

Every candidate SHALL possess:

  • Candidate Identifier;
  • proposed title;
  • proposed source type;
  • proposed publisher;
  • proposed issuing authority;
  • discovered location;
  • discovery method;
  • discovered by;
  • discovery time;
  • relevance rationale;
  • expected applicability;
  • expected rights state;
  • expected confidentiality;
  • expected transformation need;
  • status;
  • provenance.

2.1.2. Discovery Non-Authority

Discovery SHALL NOT establish authenticity, authority, legal effect, evidentiary authority, publication permission, machine-processing permission or ZAYAZ authority.

2.1.3. Automated Discovery

Automated discovery SHALL record the discovering Component, rule or query, source location, confidence, duplicate analysis, review requirement and provenance.

2.1.4. Deduplication

Deduplication SHOULD consider title, publisher, issuing authority, official identifier, edition, URL, content digest, semantic similarity, publication date and Source Series.

Similarity SHALL NOT cause automatic merge.

2.1.5. Discovery Risk

Risk MAY include unofficial copy, malicious file, counterfeit source, altered content, unknown publisher, unclear rights, personal data, trade secrets, tenant-confidential material or model-training restrictions.


2.2. Source Admission

Source Admission determines whether a candidate may enter Pergamum Pulse and under which conditions.

2.2.1. Admission Request

Every request SHALL identify the Candidate, proposed Source Object, source type, authority, expected use, scope, capture method, rights status, security classification, tenant or white-label scope, transformation need, reviewers and provenance.

2.2.2. Admission Criteria

Criteria SHALL include:

  • identifiable source;
  • identifiable publisher or origin;
  • source location;
  • relevance;
  • scope;
  • authenticity assessment;
  • rights assessment;
  • security assessment;
  • privacy assessment;
  • tenant treatment;
  • transformation feasibility;
  • storage feasibility;
  • provenance feasibility.

2.2.3. Admission Outcomes

Outcomes MAY include:

  • Admitted;
  • Admitted with Conditions;
  • Admitted for Metadata Only;
  • Admitted for Internal Processing Only;
  • Rights Review Required;
  • Authenticity Review Required;
  • Security Review Required;
  • Tenant-Restricted;
  • White-Label-Restricted;
  • Deferred;
  • Rejected;
  • Quarantined;
  • Unable to Determine.

2.2.4. Metadata-Only Admission

Metadata-only admission MAY permit source identity, title, publisher, official URL, version, publication date, rights metadata and availability metadata.

It SHALL NOT imply permission to store source bytes or reproduce content.

2.2.5. Internal-Only Admission

Internal-only admission SHALL define permitted users, Components, processing, publication prohibition, export prohibition, retention, deletion and review date.

2.2.6. Rejection

Rejection SHALL preserve reason, authority, evidence, reconsideration conditions and provenance.

2.2.7. Admission Receipt

A receipt SHOULD contain Candidate, Source Object, decision, conditions, permitted uses, prohibited uses, scope, reviewers and provenance.


2.3. Source Classification and Authority Assessment

Every admitted source SHALL be classified before transformation.

2.3.1. Source Types

Source Types MAY include law, regulation, regulatory guidance, court decision, standard, certification scheme, accreditation scheme, assurance standard, methodology, manufacturer manual, technical data sheet, firmware release note, protocol specification, API specification, dataset, scientific paper, supplier document, contract, certificate, internal Viroway document, EcoWorld publication, tenant document, white-label document and derived synthesis.

2.3.2. Authority Assessment

Authority assessment SHALL separately evaluate:

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

2.3.3. Authority Scope

Authority SHALL be bounded by subject, jurisdiction, product, model, firmware, period, organisation role, publication status, certification scope and evidentiary purpose.

2.3.4. Official Source

A source MAY be classified official where obtained from the issuing authority, authorised publisher, official Registry, official repository, verified API or authorised contractual delivery.

2.3.5. Secondary and Unofficial Sources

A secondary or unofficial source SHALL identify the original source where known, transformation, limitations and inability to substitute for original authority where official evidence is required.

2.3.6. Composite and Derived Sources

Composite and derived sources SHALL identify every constituent source, transformation, author, authority, uncertainty, rights and limitations.


2.4. Source Authenticity and Integrity

Authenticity establishes whether a source is what it claims to be.

Integrity establishes whether captured content remained unaltered from acquisition.

2.4.1. Authenticity Evidence

Evidence MAY include official domain, repository, digital signature, publisher certificate, trusted timestamp, authenticated portal, contractual delivery, official API, Registry lookup, published checksum or direct confirmation.

2.4.2. Authenticity States

Authenticity state SHALL be represented independently from source authority.

The canonical authenticity states are governed by the Pergamum Pulse Authenticity State Registry and SHALL map one-to-one between the normative label and the machine-readable state key:

Normative stateMachine-readable key
Verifiedverified
Verified with Conditionsverified_with_conditions
Probableprobable
Unverifiedunverified
Conflictingconflicting
Counterfeitcounterfeit
Alteredaltered
Unable to Determineunable_to_determine

Evidence describing why an authenticity state was assigned SHALL remain separate from the state itself.

Authenticity evidence MAY include, without creating additional authenticity states:

  • official-domain or official-repository evidence;
  • digital signature or publisher-certificate evidence;
  • trusted timestamp evidence;
  • authenticated-portal evidence;
  • contractual-delivery evidence;
  • official-API evidence;
  • Registry lookup;
  • published checksum;
  • direct confirmation;
  • verified-copy comparison;
  • conflicting evidence;
  • suspected alteration evidence.

A verified official source, a verified authentic original and a verified copy MAY therefore all resolve to the canonical state verified, while preserving their distinct evidence basis.

A suspected alteration SHALL NOT be represented as confirmed altered unless the applicable evidence and review support that conclusion.

Authenticity SHALL NOT imply source authority, legal authority, evidentiary authority, ZAYAZ governance authority or Runtime authority.

2.4.3. Integrity Digest

Every stored source byte object SHOULD possess a cryptographic digest.

2.4.4. Signature Validation

Signature validation SHALL record signature type, signer, certificate, trust anchor, signing time, validation time, revocation state, result and provenance.

2.4.5. Web Capture

Web capture SHOULD preserve requested URL, resolved URL, redirect chain, retrieval time, status, relevant headers, content type, digest, page title, canonical link, archive reference and provenance.

2.4.6. API Capture

API capture SHOULD preserve endpoint, method, parameters, authentication class without secrets, response headers, pagination, query time, digest, schema version and provenance.

2.4.7. Uploaded Source

An upload SHALL preserve uploader, scope, upload time, original filename, digest, declared source, declared rights, malware scan, review state and provenance.

2.4.8. Counterfeit Source

A counterfeit source SHALL be quarantined and linked to claimed source, detection evidence, affected documents, assertions, projections and incident response.


2.5. Capture Planning and Execution

2.5.1. Capture Plan

A material Capture Plan SHOULD define Source Object, location, acquisition method, credentials class, expected format, size, rights, frequency, monitoring strategy, security, storage, retention, responsible Component, Role and provenance.

2.5.2. Capture Scope

Capture scope SHALL identify whether it includes:

  • complete source;
  • metadata only;
  • selected pages;
  • selected clauses;
  • selected records;
  • selected API fields;
  • selected media;
  • delta only.

2.5.3. Complete Source Preference

Where lawful and feasible, Pergamum Pulse SHOULD preserve the complete source capture used for transformation.

2.5.4. Partial Capture

Partial capture SHALL identify captured scope, omitted scope, reason, impact, rights basis and provenance.

2.5.5. Capture Failure

Failure SHALL preserve attempted source, method, time, error, partial content, retry state, fallback and provenance.

2.5.6. Capture Immutability

A completed Source Capture SHALL be immutable. Correction SHALL create a new capture or correction record.


2.6. Chain of Custody and Preservation

2.6.1. Chain-of-Custody Event

Every event SHALL identify event identity, source or capture, prior custodian, new custodian, action, time, location, digest before, digest after, authority and provenance.

2.6.2. Custody Actions

Actions MAY include acquisition, transfer, storage, verification, decryption, decompression, extraction, transformation, review, export, archive and destruction.

2.6.3. Original Bytes

Original bytes SHALL be preserved separately from transformed outputs where lawful.

2.6.4. Container Preservation

Where a source is contained in an archive, email or package, both container and extracted members SHOULD be preserved.

2.6.5. Access and Encryption

Restricted sources SHOULD be encrypted. Access SHALL be least-privilege and logged.

2.6.6. Replication

Replication SHALL preserve digest, location, encryption, tenant scope, access policy, retention and provenance.

2.6.7. Destruction

Destruction SHALL require rights or contractual basis, retention expiry, no Legal Hold, no active dependency, authority, destruction evidence and provenance.


Every source and Knowledge Document SHALL possess or reference a Rights Record.

2.7.1. Rights Record

A Rights Record SHALL include:

  • Rights Record Identifier;
  • source or target object;
  • copyright notice;
  • copyright holder;
  • copyright year;
  • licence;
  • permission basis;
  • publication rights;
  • redistribution rights;
  • modification rights;
  • quotation rights;
  • processing rights;
  • attribution;
  • evidence;
  • valid time;
  • status;
  • provenance.

Authorship SHALL NOT automatically establish ownership.

Ownership evidence MAY include employer ownership, contractor assignment, transfer, licence, joint-authorship agreement, public-domain status, statutory rule or publisher agreement.

2.7.3. Viroway-Authored Documents

Viroway-authored documents SHALL identify author, commissioning context, employee or contractor basis, copyright holder, copyright year, approval, publication permission, redistribution terms, internal-use terms, external-use terms and provenance.

2.7.4. Third-Party Sources

Third-party sources SHALL identify copyright holder, publisher, licence, rights URL, agreement reference, permitted uses, prohibited uses, attribution, expiration and revocation.

2.7.5. Rights by Use

Rights SHALL be evaluated separately for:

  • storage;
  • backup;
  • parsing;
  • OCR;
  • translation;
  • summarisation;
  • structured extraction;
  • quotation;
  • reproduction;
  • modification;
  • derivative work;
  • semantic indexing;
  • embeddings;
  • vector storage;
  • retrieval-augmented generation;
  • model evaluation;
  • fine-tuning;
  • foundation-model training;
  • public generation;
  • redistribution;
  • commercial publication;
  • derivative dataset creation.

2.7.6. Most-Restrictive Rule

Where multiple rules apply, the most restrictive applicable rule SHALL prevail unless authorised legal review determines otherwise.

2.7.7. Rights Scope

Rights SHALL identify territory, audience, organisation, tenant, white-label operator, purpose, channel, duration, volume, language and medium.

2.7.8. Rights Expiration and Revocation

Expiration or revocation SHALL trigger review of processing, Publication, embeddings, model use, access, retention and affected projections.


2.8. Citation, Quotation and Publication Rights

Every external citation SHALL preserve source identity and the basis permitting use.

2.8.1. Citation Object

A Citation Object SHALL identify source, locator, quoted or paraphrased state, language, transformation, attribution, Rights Record, publication permission, access time and provenance.

2.8.2. Source Locator

A locator MAY be page, clause, article, paragraph, table, row, cell, figure, diagram, dataset record, API field, timestamped segment or code block.

2.8.3. Quotation and Paraphrase

Quotation SHALL identify exact fragment, length, rights basis, attribution and audience.

Paraphrase SHALL identify source, locator, transformation, reviewer, controlling source and rights basis.

2.8.4. Data Citation

A data citation SHALL identify dataset, version, records, extraction query, fields, transformation, aggregation, licence, database rights and publication permission.

2.8.5. Media Reuse

Figures, diagrams, photographs and other media SHALL be rights-reviewed independently where required.

2.8.6. Citation Rights Gate

Publication SHALL be blocked where source is unidentified, locator missing, rights unresolved, attribution missing, publication prohibited, quotation excessive or confidential content exposed.

2.8.7. Viroway Citation

Viroway-authored material SHALL still identify source document, version, copyright, publication status and approved source URL or controlled location.


2.9. Transformation Planning

Every material transformation SHOULD possess a Transformation Plan.

2.9.1. Transformation Plan

A Plan SHALL identify source capture, intended Knowledge Document, representation type, processing steps, tools, models, parsers, OCR, translation, expected coverage, omissions, rights permissions, reviewers, quality criteria, classification and provenance.

2.9.2. Transformation Types

Types MAY include verbatim transcription, structured transcription, structured extraction, normalised representation, paraphrase, summary, translation, interpreted guidance, composite synthesis, machine-generated draft, human-authored source and human-reviewed extraction.

2.9.3. Transformation Authority

Transformation authority SHALL be limited to the permitted use. Permission to summarise SHALL NOT imply permission to reproduce.

2.9.4. Transformation Environment

The environment SHALL identify tenant scope, white-label scope, network controls, model provider, retention, logging, export, human access and provenance.

2.9.5. External Model Use

Before source content is sent to an external model provider, the system SHALL verify contractual permission, confidentiality, retention, training use, jurisdiction, tenant permission, rights permission and security approval.


2.10. Parsing, OCR, Translation and Normalisation

2.10.1. Parsing

Parsing SHALL record parser, version, input format, output format, structural coverage, errors, unsupported elements and provenance.

2.10.2. OCR

OCR SHALL be used only where necessary and rights-permitted.

OCR metadata SHALL identify engine, version, language, pages, confidence, preprocessing, manual correction, unresolved regions and provenance.

2.10.3. Translation

Translation SHALL identify source language, target language, translator or model, version, profile, legal status, review, ambiguity, controlling language and provenance.

2.10.4. Controlling Language

Where a translation is not legally controlling, metadata SHALL state this explicitly.

2.10.5. Normalisation

Normalisation MAY include heading hierarchy, whitespace, encoding, dates, units, identifiers, table structure, citations and links.

It SHALL NOT alter substantive meaning silently.

2.10.6. Formula, Table and Figure Preservation

Formulas, tables and figures SHALL preserve source representation, normalised representation, units or labels, source locator, rights, validation and provenance.


2.11. AI-Assisted Extraction and Review

AI MAY assist with classification, section detection, table extraction, entity detection, assertion extraction, relationship detection, summarisation, translation, change detection, citation alignment and rights-risk flagging.

AI SHALL NOT independently establish copyright ownership, grant publication rights, determine disputed legal effect, ratify authority, approve Change Candidates, activate projections or publish restricted content.

2.11.1. AI Transformation Record

Every material AI transformation SHALL identify Transformation Identifier, model, model version, provider, Agent Profile, prompt profile, retrieval sources, tool calls where material, input, output, generation time, confidence, reviewer and provenance.

2.11.2. Prompt Versioning

Prompts and extraction profiles SHALL be versioned where they materially affect output.

2.11.3. Retrieval Provenance

Retrieval-assisted extraction SHALL preserve retrieved sources, fragments, ranking, access scope, rights, time, model context and provenance.

2.11.4. Confidence Non-Authority

AI confidence SHALL NOT be treated as proof.

2.11.5. Unsupported Claims

Potentially unsupported claims SHALL be flagged, linked to missing evidence, excluded from approved assertions, reviewed and provenance-preserved.

2.11.6. Human Review

Human review SHALL be required where output concerns legal obligations, certification requirements, publication rights, safety limits, device accuracy, formulas, thresholds, contractual duties, tenant-impacting rules, Runtime activation or public claims.

2.11.7. Review Outcomes

Outcomes MAY include Approved, Approved with Conditions, Partially Approved, Correction Required, Additional Evidence Required, Rejected, Quarantined and Unable to Determine.


2.12. Coverage, Omission, Confidence and Quality

2.12.1. Source Coverage

Coverage SHALL identify complete or partial state, pages, sections, clauses, tables, figures, annexes, records, API fields, omissions, reason and provenance.

2.12.2. Omission Record

Every material omission SHALL identify omitted fragment, reason, rights basis, technical limitation, relevance decision, impact, reviewer and provenance.

2.12.3. Coverage States

States MAY include Complete, Complete Except Controlled Omissions, Substantially Complete, Partial, Materially Incomplete, Unknown and Unable to Determine.

2.12.4. Confidence Dimensions

Confidence SHOULD be separated into authenticity, parse, OCR, translation, extraction, semantic, rights and applicability confidence.

2.12.5. Quality Criteria

Quality MAY include structural completeness, semantic accuracy, citation completeness, rights completeness, source coverage, reproducibility, reviewer agreement, unresolved ambiguity and transformation consistency.

2.12.6. Transformation Reproducibility

A transformation SHOULD be reproducible from exact Source Capture, tool versions, model versions, prompt profiles, configuration and rights context.

2.12.7. Transformation Drift

Drift exists where the same source produces materially different outputs due to parser, OCR, model, prompt, translation, rights filtering or profile changes.

Material drift SHALL trigger comparison, impact analysis, review, assertion reassessment and projection reassessment.


2.13. Quarantine, Withdrawal and Rights Change

2.13.1. Quarantine Triggers

Triggers MAY include authenticity failure, malware, counterfeit source, unresolved rights, rights prohibition, tenant-scope ambiguity, confidential leakage, corrupted source, corrupted transformation, unsupported AI assertions, incomplete provenance or source conflict.

2.13.2. Quarantine Record

A quarantine record SHALL identify source or object, reason, authority, start time, scope, access restrictions, permitted investigation, release criteria, destruction criteria and provenance.

2.13.3. Source Withdrawal

Withdrawal MAY occur because an authority withdraws the source, the source is superseded, licence expires, rights are revoked, the source is counterfeit, use becomes prohibited, a tenant requests deletion, contractual retention ends or the source is defective.

2.13.4. Withdrawal Impact Analysis

Analysis SHALL cover Knowledge Documents, Sections, Fragments, Assertions, Entities, mappings, Change Candidates, projections, Runtime state, Publications, embeddings, vector stores, training datasets, tenants, white-label deployments and historical records.

2.13.5. Historical Preservation

Withdrawal SHALL distinguish historically valid until withdrawal, invalid from inception, no longer current, prohibited from future use, deletion required and Legal Hold retention.

2.13.6. Rights Change

A rights change SHALL create a new Rights Record version and SHALL NOT silently rewrite prior history.

2.13.7. Processing Revocation

Revocation SHALL identify affected parsers, OCR outputs, summaries, assertions, embeddings, indexes, training datasets, derivative datasets and public outputs.

2.13.8. Publication Retraction

Where published content is no longer permitted or accurate, the CPF SHALL govern correction, qualification, restatement, supersession, withdrawal and notice.

2.13.9. Quarantine Release

Release SHALL require trigger resolution, authenticity, rights, security, provenance and reviewer approval.


2.14. Part II Provenance and Conformance

Part II provenance SHALL connect:

  • Source Candidate;
  • discovery event;
  • Admission Request;
  • Admission Decision;
  • Source Object;
  • Source Series;
  • authority assessment;
  • authenticity evidence;
  • Capture Plan;
  • Source Capture;
  • original bytes;
  • digest;
  • signature;
  • custody events;
  • Rights Record;
  • licence;
  • agreement;
  • rights evidence;
  • Citation Object;
  • Transformation Plan;
  • parser;
  • OCR;
  • translation;
  • AI model;
  • prompt profile;
  • review;
  • source coverage;
  • omission;
  • confidence;
  • quality Findings;
  • quarantine;
  • withdrawal;
  • rights change;
  • affected projections;
  • Module lineage;
  • Component lineage;
  • tenant lineage;
  • white-label lineage;
  • temporal lineage.

HECATE SHALL validate objective structure including source identity, version, official-source metadata, capture identity, digest, signature metadata, rights completeness, processing permissions, citation structure, transformation identity, parser and model versions, coverage, omissions, review, quarantine, withdrawal, lineage and provenance.

HECATE SHALL NOT create legal rights, infer ownership, grant publication permission, determine disputed legal meaning, increase source authority or validate unsupported assertions as true.


Part II Conformance

An implementation conforms to Part II where it:

  1. preserves identifiable Source Candidates and discovery events;
  2. prevents discovery from establishing authority or rights;
  3. performs explicit Source Admission;
  4. supports conditional, metadata-only, internal-only, rejected and quarantined admission outcomes;
  5. classifies source, legal and evidentiary authority separately;
  6. distinguishes official, secondary, unofficial, composite and derived sources;
  7. validates authenticity independently from authority;
  8. preserves integrity digests and signature metadata;
  9. preserves web, API and upload acquisition context;
  10. plans material capture activities;
  11. distinguishes complete, partial and delta capture;
  12. preserves immutable Source Captures;
  13. preserves original bytes separately from transformed outputs where lawful;
  14. preserves chain of custody;
  15. encrypts and access-controls restricted sources;
  16. assigns Rights Records to sources and Knowledge Documents;
  17. records copyright for external and Viroway-authored documents;
  18. records ownership or permission basis;
  19. distinguishes storage, parsing, OCR, translation, extraction, quotation, reproduction, embedding, RAG, evaluation, fine-tuning, training, publication and redistribution rights;
  20. applies the most restrictive applicable rights rule;
  21. preserves territory, audience, tenant, white-label, purpose, channel and duration scope;
  22. monitors licence expiration and revocation;
  23. links citations to source and rights evidence;
  24. preserves exact citation locators;
  25. treats figures, diagrams, photographs and datasets as independently rights-sensitive where required;
  26. blocks Publication where source, locator, attribution or rights are unresolved;
  27. governs transformations through identifiable Plans;
  28. prevents transformation from increasing authority or rights;
  29. records parser, OCR, translation, model and prompt versions;
  30. records controlling language and translation limitations;
  31. validates external-model use against confidentiality, rights, retention and training restrictions;
  32. prevents AI from granting rights, legal authority or activation;
  33. requires competent human review for high-impact uses;
  34. preserves coverage and omissions;
  35. separates confidence dimensions;
  36. detects transformation drift;
  37. quarantines sources with authenticity, rights, security, tenancy or provenance defects;
  38. performs withdrawal impact analysis across documents, assertions, mappings, projections, Runtime, Publications, embeddings and training datasets;
  39. preserves historical rights and withdrawal state;
  40. integrates CPF correction and retraction controls;
  41. preserves Module lineage;
  42. preserves Component lineage;
  43. preserves tenant and white-label lineage;
  44. preserves complete bitemporal Part II provenance.

Part II Foundational Principle

Pergamum Pulse SHALL know not only what a source says, but where it came from, whether it is authentic, what authority it has, what Viroway is permitted to do with it, how it was transformed and whether the resulting representation remains trustworthy.

A source may be public and still be copyrighted. It may be authentic and still be outdated. It may be official and still be non-binding. It may be licensed for reading but not for extraction, embedding, model training or public reproduction. It may be machine-readable and still require professional review.

Every capture SHALL preserve original evidence. Every rights decision SHALL be use-specific. Every transformation SHALL be attributable. Every omission SHALL remain visible. Every AI-generated result SHALL remain distinguishable from source content. Every withdrawal SHALL preserve historical truth while preventing unauthorised future use.

By making admission, authenticity, chain of custody, rights, citation, transformation, review, quarantine and withdrawal first-class governed processes, Pergamum Pulse can acquire knowledge at global scale without sacrificing legal defensibility, evidentiary integrity, tenant isolation or constitutional authority.




GitHub RepoRequest for Change (RFC)