Pergamum Pulse — Regulation, XBRL and FOGE Semantic Reconciliation

1. Purpose

This architecture defines how ZAYAZ combines three different forms of intelligence to produce stronger, more complete and more deterministic FOGE definitions:

authoritative regulation and methodology, which determine what is required and under which conditions;
official XBRL taxonomy semantics, which describe how reporting concepts, dimensions and relationships are digitally represented; and
AI-assisted semantic analysis, which accelerates discovery, comparison, candidate mapping, gap detection and compilation support without creating authority.

The architecture exists because none of these inputs is sufficient on its own.

Regulatory prose may express the legal or methodological obligation but leave digital reporting structure implicit. XBRL may provide precise concepts, dimensions, members, presentation networks and calculation relationships but does not by itself establish legal applicability or methodological authority. AI can compare both at a scale and depth that would be expensive to perform manually, but AI output is analytical evidence and candidate reasoning rather than admitted authority.

ZAYAZ therefore uses Pergamum Pulse as the governed reconciliation plane, PP-MAP as the admitted semantic bridge, FOGE as the governed interaction compiler, SSSR as the governed signal-discovery and resolution-binding layer, ZSSR as the governed runtime routing-decision layer, and DaVE Dispatcher plus selected downstream engines/workflows as the execution layer.

The governing principle is:

Regulation and methodology determine what must be satisfied; XBRL contributes exact digital-reporting semantics; AI may propose how the two correspond; governed PP-MAP admission establishes the approved bridge; FOGE compiles the approved semantics into executable Data Needs and interaction structures; SSSR determines the governed signal identity and resolution path; ZSSR produces the governed routing decision; and DaVE Dispatcher plus the selected downstream engine or workflow execute/materialize the selected route and return the resulting observation to FOGE.

2. Core constitutional invariants

The following invariants SHALL remain true throughout the architecture.

2.1 XBRL does not create the legal requirement

The presence of a taxonomy concept, label, reference, dimension, member, formula or relationship SHALL NOT be interpreted as proof that an undertaking is legally required to disclose it.

Legal and methodological obligation remains grounded in admitted Pergamum source and requirement semantics.

2.2 Regulation does not define physical data location

A requirement may define the information that must exist, its population, grain, dimensions, evidence expectations and methodological rules. It SHALL NOT be treated as authority for a PostgreSQL column, API endpoint, source system or tenant-specific value.

Physical resolution belongs downstream through SSSR-governed signal discovery/binding, ZSSR-governed routing decisions, and DaVE/downstream-executor materialization.

2.3 AI does not create authority

AI MAY:

extract candidate semantics;
propose requirement-to-XBRL mappings;
compare regulatory text and taxonomy networks;
classify likely dimensions and members;
detect disagreement and semantic gaps;
propose FOGE Data Need structures;
propose candidate SSSR signal requirements;
generate explanations and review packages.

AI SHALL NOT silently create:

legal authority;
methodological authority;
PP-MAP approval;
runtime activation;
publication authority;
redistribution authority;
an admitted requirement;
an admitted SSSR semantic identity.

2.4 PP-MAP is a governed bridge, not a guess

Candidate correspondence between Pergamum semantics and XBRL semantics MAY be produced by deterministic rules, taxonomy references, AI or hybrid analysis.

An approved mapping SHALL be represented by a separately governed PP-MAP object version. Candidate rows SHALL NOT be promoted in place into authority.

A downstream FOGE-to-XBRL binding row SHALL NOT be treated as proof that PP-MAP admission occurred. The binding layer may structurally pin a PP-MAP-shaped object reference and exact taxonomy coordinates, while the authoritative admission decision remains owned by Pergamum mapping governance and must be validated separately before governed compilation or publication of the FOGE definition.

Admission alone is also insufficient to authorize every use. Before FOGE consumes an admitted PP-MAP for compilation, the governing validation gate SHALL verify the mapping direction and the exact purpose-authorizing PP-MD decision. The PP-MAP must authorize traversal from the governed Pergamum requirement toward the exact XBRL semantic target for this compilation use, and the PP-MD must explicitly permit the exact foge_compilation purpose. Approval for internal analysis SHALL NOT be presumed to authorize compilation. FOGE definition publication is a separate later material use and SHALL be authorized only by the fresh publication-time gate defined below; compilation-time authorization SHALL NOT require or imply foge_definition_publication.

Any gate that relies on the PP-SMCS v0.2 machine-enforceable direction or purpose semantics SHALL consume Core 2-conformant PP-MAP and PP-MD object versions. Historical Core 1 Mapping Objects and Mapping Decisions remain replayable only under their original immutable contracts; they SHALL NOT acquire Core 2 authority merely because legacy free-form values happen to resemble Core 2 direction or purpose identifiers. A governed migration must create Core 2-conformant successor versions before downstream automation relies on the v0.2 guarantees.

Governed review MAY resolve incomplete, ambiguous or contradictory evidence before an authorization determination. It SHALL NOT waive a failed constitutional authorization predicate for the exact governed artifact/version under evaluation. If review produces, corrects, migrates, supersedes or approves a different governed artifact/version, the complete authorization gate SHALL be evaluated again against that resulting artifact/version.

2.5 FOGE does not reinterpret source law at runtime

FOGE consumes governed requirement execution semantics. It SHALL compile those semantics into reusable Data Needs, requirement-specific Data Need Uses, interaction Items, resolution paths and runtime projections without independently re-reading or reinterpreting legislation at runtime.

2.6 SSSR describes governed resolution; ZSSR decides routing; executors materialize

SSSR determines what governed signal object corresponds to a semantic Data Need and how ZAYAZ may reach or construct it. Its design-time resolution capability is STORED, DERIVABLE, ACQUIRABLE or UNRESOLVED.

SSSR SHALL NOT become the runtime executor. Where an executable route exists, the pinned FOGE/SSSR materialization need is handed into the ZSSR routing plane. ZSSR SHALL produce the governed routing decision or routing hint; it SHALL NOT itself move data or perform the selected downstream computation/acquisition. DaVE Dispatcher and the selected downstream engine, connector, agent or governed workflow execute the route. The resulting resolution observation returns to FOGE for validation, evidence/trust evaluation and item-state determination.

Runtime outcomes such as an actually derived or acquired value SHALL remain runtime state and SHALL NOT rewrite the underlying Pergamum requirement meaning.

2.7 Activation, definition publication, external publication and legal authority remain separate

A taxonomy may be registered without being runtime-active. It may be usable for internal semantic analysis without being authorised for customer display or external publication. A runtime-active taxonomy does not thereby become legal authority.

FOGE separately owns publication and immutability rules for its own compiled definitions, including governed framework releases, Form Versions, Data Need Versions and Item Versions. Publishing those immutable FOGE definitions does not grant customer/report/taxonomy publication, filing, public API exposure or redistribution authority. Those external audience-facing transitions remain separately governed.

3. The three semantic planes

The architecture separates three planes that are often incorrectly collapsed in conventional ESG systems.

Plane	Governing question	Primary authority
Regulation and methodology	What must be satisfied, by whom, when, and under which methodological conditions?	Pergamum Pulse admitted source and requirement semantics
Digital reporting semantics	How does an official taxonomy represent reporting concepts, dimensions, members and relationships?	Exact registered XBRL taxonomy release
Executable interaction semantics	What semantic information must FOGE obtain, validate, derive, confirm or request?	FOGE compiled release bound to exact Pergamum and PP-MAP authority

These planes are complementary rather than interchangeable.

Conceptually:

Authoritative Regulation / Methodology
                │
                │  obligation, applicability,
                │  scope, method, evidence
                ▼
         Pergamum Requirement
                │
                │
                ├──────────── semantic reconciliation ────────────┐
                │                                                 │
                ▼                                                 ▼
         FOGE Data Need                                    XBRL Taxonomy
   "what information is needed"                    "how reporting is modelled"
                │                                                 │
                └────────────────── PP-MAP ───────────────────────┘
                                     │
                                     ▼
                              FOGE Compilation

4. End-to-end architecture

The complete governed path is:

Official Regulation / Standard / Methodology
                    │
                    ▼
            Pergamum Pulse
      source custody + interpretation
                    │
                    ▼
       Governed Requirement Semantics
                    │
                    ▼
   Published Requirement Execution Package
     exact package + requirement versions
                    │
                    │
          ┌─────────┴─────────┐
          │                   │
          │                   ▼
          │           Official XBRL Package
          │                   │
          │                   ▼
          │           Governed XBRL Projection
          │           concepts + relationships
          │                   │
          └────────► Semantic Reconciliation ◄────────┐
                         │                             │
                         │                    AI / deterministic
                         │                    candidate analysis
                         ▼                             │
                    PP-MAP                            │
               governed approved bridge              │
                         │                             │
                         └─────────────┬───────────────┘
                                       ▼
                                      FOGE
                         governed interaction compiler
                                       │
                              Semantic Data Needs
                                       │
                                       ▼
                                      SSSR
                  governed signal identity + route description
                                       │
                 STORED / DERIVABLE / ACQUIRABLE / UNRESOLVED
                                       │
                      resolvable binding │ unresolved
                                       │       └──► blocked/manual path
                                       ▼
                 FOGE/SSSR → ZSSR materialization handoff
                                       │
                                       ▼
                                      ZSSR
                         governed routing decision / hint
                                       │
                                       ▼
                       DaVE Dispatcher / selected executor
                         route execution + materialization
                                       │
                                       ▼
                         resolution observation to FOGE
                                       │
                                       ▼
                            FOGE Runtime Projection
                       ┌───────────────┴───────────────┐
                       │                               │
                  zero-question                  Delta Form /
                    outcome                   confirmation / input
                       │                               │
                       └───────────────┬───────────────┘
                                       ▼
                             Governed ESG Outcome
                                       │
                                       ▼
                         XBRL validation / tagging
                                       │
                                       ▼
                          Reports / filing workflow

The architecture forms a semantic loop rather than a one-way export pipeline.

5. Pergamum regulation and methodology semantics

Pergamum Pulse owns the authoritative execution semantics that downstream systems need in order to satisfy a regulatory or methodological requirement without reinterpreting its meaning.

A governed requirement may include:

requirement identity and exact version;
authoritative source lineage;
jurisdiction;
legal or methodological effective dates;
obligation state;
applicability rules;
thresholds;
reporting boundary;
reporting period;
subject and object scope;
population rules;
required information;
value kind;
grain;
dimensions and classifications;
completeness expectations;
evidence expectations;
attestation requirements;
allowed alternatives;
derivation permissions;
estimation permissions;
calculation permissions;
methodological constraints;
units or unit constraints where governed;
source citations;
supersession and amendment relationships.

Pergamum should therefore be able to express a requirement such as:

requirement:
  requirement_ref: <governed-requirement>
  requirement_version: <exact-version>

  obligation: mandatory

  data_needs:
    - need_key: workforce_gender_distribution
      value_kind: structured_collection

      grain:
        subject: business_unit
        period: reporting_period

      dimensions:
        - business_unit
        - gender_category

      measure:
        concept: headcount
        aggregation: count

      completeness:
        population: all_business_units_in_scope

      derivation:
        permitted: true

      estimation:
        permitted: false

This describes what must be produced and the conditions under which it is valid.

It does not identify a database table, user-interface control or physical source system.

6. XBRL as a digital semantic graph

An official XBRL taxonomy provides a second semantic view of the same reporting domain.

Pergamum Pulse SHOULD preserve and query at least:

exact taxonomy release identity;
exact taxonomy package digest;
exact concept QName;
namespace and local name;
data type;
substitution group;
period type;
balance where relevant;
abstract and nillable state;
multilingual labels;
concept references;
presentation relationships;
calculation relationships;
definition relationships;
dimensional relationships;
domains and members;
hypercubes;
formulas where present;
entry points and network roles;
provider metadata and provenance.

This graph is useful before any report exists.

It can help answer questions such as:

Does the digital taxonomy distinguish concepts that regulatory prose describes together?
Does a disclosure require a dimension rather than multiple independent metrics?
Which domain members are expected?
Which concepts are abstract containers rather than reportable facts?
Which duration or instant semantics apply?
Which calculation or presentation relationships reveal intended structure?
Which taxonomy references point back to relevant regulatory passages?
Does the taxonomy contain a concept for a requirement that Pergamum has not yet reconciled?
Does Pergamum require information for which no suitable taxonomy concept exists?

XBRL therefore acts as technical semantic evidence and a digital reporting ontology, not merely a final export vocabulary.

7. PP-MAP as the reconciliation authority

The central bridge is PP-MAP.

A PP-MAP object represents an approved semantic relationship between governed Pergamum meaning and an external or downstream semantic object.

For regulation-to-XBRL reconciliation, the approved mapping SHOULD bind at minimum:

exact Pergamum object/version
        ↕
exact PP-MAP object/version
        ↕
exact XBRL taxonomy release
        +
exact QName
        +
role / usage
        +
dimensional context
        +
provenance

The mapping role may include concepts such as:

primary_datapoint
supporting_concept
dimension
member
domain
validation_context

The mapping usage may distinguish:

reportable_fact
dimension_axis
dimension_member
domain_member
validation_only
presentation_only

This allows FOGE to know not merely that a requirement and an XBRL concept are "similar", but how the exact XBRL semantic object participates in the governed Data Need.

The authority of that relationship comes from the admitted PP-MAP and its exact, effective PP-MD decision. A foreign key or prefix check in a downstream FOGE relation is structural integrity only; it is not a substitute for validating PP-MAP admission, exact source identity, exact target identity, mapping direction, decision purpose and the governed mapping semantics.

Where a downstream use relies on PP-SMCS v0.2 direction or purpose authorization, the exact Mapping Object and Mapping Decision SHALL declare the PP-SMCS Core 2.0 mapping-object and mapping-decision schema identities. A historical Core 1 object MAY remain part of replay evidence, but it SHALL NOT be interpreted as Core 2-conformant authority unless a governed migration has produced the corresponding Core 2-conformant successor version.

8. Candidate reconciliation before PP-MAP admission

Candidate reconciliation is analytical and may use several evidence classes.

8.1 Deterministic evidence

Examples include:

exact source citation match;
taxonomy reference pointing to the same paragraph or disclosure requirement;
exact identifier correspondence;
governed lookup relationship;
identical controlled classification;
deterministic structural rule.

8.2 Semantic evidence

Examples include:

concept and requirement meaning similarity;
label similarity;
definition similarity;
compatible grain;
compatible period type;
compatible data type;
compatible dimensions;
compatible population and scope;
calculation-network consistency;
presentation-network consistency.

8.3 Hybrid evidence

The strongest candidate mappings may combine deterministic and AI-assisted reasoning.

Conceptually:

Regulatory source fragment
        +
Governed requirement semantics
        +
XBRL concept labels/references
        +
XBRL network structure
        +
Methodological constraints
        │
        ▼
Candidate Mapping Analysis
        │
        ├── deterministic evidence
        ├── taxonomy-reference evidence
        ├── AI semantic evidence
        ├── structural compatibility
        └── contradiction checks
        │
        ▼
Candidate PP-MAP Review Package
        │
        ▼
Governed admission / rejection / unresolved

A candidate that is not sufficiently supported SHALL remain candidate or unresolved.

9. Canonical reconciliation dimensions and diagnostic findings

Reconciliation SHALL reuse the governed Pergamum Pulse mapping vocabularies rather than introduce a parallel monolithic outcome enum.

The normative owner for mapping semantics is PP-SMCS. At minimum, reconciliation uses three independent governed dimensions: mapping type, direction and cardinality.

9.1 Mapping type

mapping_type SHALL resolve through the canonical Pergamum Pulse Mapping Type Registry.

Representative governed values include:

exact_equivalent
semantic_equivalent
broader_than
narrower_than
partial_overlap
conditional_equivalent
compatible_with
incompatible_with
conflicts_with
no_mapping
unresolved

Other mapping types SHALL be used only when they are present in the canonical registry.

9.2 Mapping direction

direction SHALL resolve through the canonical Pergamum Pulse Mapping Direction Registry.

The current governed values are:

directed
inverse_directed
bidirectional
symmetric
derived_inverse
non_reversible

Direction is independent of both semantic mapping type and cardinality. A validator SHALL interpret the exact PP-MAP source and target together with the governed direction under PP-SMCS and SHALL prove that the intended traversal is authorized.

For the FOGE regulation-to-XBRL use described by this chapter, the required traversal is from the exact governed Pergamum requirement semantics toward the exact XBRL semantic target. Merely having the expected objects on the source and target sides is insufficient if the admitted direction does not authorize that traversal. No implementation SHALL infer reversibility from semantic similarity, cardinality or approval state.

9.3 Mapping cardinality

cardinality SHALL resolve through the canonical Pergamum Pulse Mapping Cardinality Registry.

The current governed values are:

one_to_one
one_to_many
many_to_one
many_to_many
one_to_zero_or_one
conditional
unconstrained
unresolved

Mapping type, direction and cardinality answer different questions and SHALL NOT be collapsed into one status.

For example:

mapping_type: partial_overlap
direction: directed
cardinality: one_to_many

is materially different from:

mapping_type: exact_equivalent
direction: bidirectional
cardinality: one_to_one

9.4 Diagnostic findings remain separate from mapping identity

Reconciliation also needs to explain why a candidate is compatible, incomplete or unresolved. Diagnostic findings may describe conditions such as:

dimensional incompatibility;
grain incompatibility;
temporal incompatibility;
methodology incompatibility;
unit incompatibility;
population or scope incompatibility;
taxonomy-only semantics with no admitted Pergamum requirement correspondence;
requirement semantics for which no adequate XBRL target is identified;
unresolved ambiguity among several plausible candidates.

These descriptions are diagnostic evidence, not new mapping-type, direction or cardinality values. If ZAYAZ later requires machine-persisted controlled diagnostic codes, those codes SHALL be registered through their normative owner rather than invented inside FOGE, XBRL or AI implementation logic.

This separation allows ZAYAZ to explain both what the governed relationship is and what evidence or incompatibility led to that decision without bypassing canonical PP mapping registries.

10. AI role

AI is a semantic intelligence layer around the governed pipeline.

10.1 AI-assisted source interpretation

AI MAY assist Pergamum with:

fragment classification;
definition extraction;
requirement decomposition;
applicability candidate extraction;
threshold extraction;
cross-reference resolution;
methodology-step extraction;
table and annex interpretation;
candidate data-need identification;
candidate evidence expectations;
change-impact analysis across source versions.

All material outputs remain evidence-bound candidates until governed processes admit them.

10.2 AI-assisted XBRL interpretation

AI MAY reason over:

concept labels;
references;
documentation;
QName morphology;
presentation networks;
definition networks;
dimensional structures;
calculation networks;
formula relationships;
surrounding concepts;
taxonomy release changes.

10.3 AI-assisted semantic reconciliation

AI MAY compare regulation/methodology with XBRL and propose:

candidate primary datapoints;
supporting concepts;
dimensions;
members;
domains;
validation context;
mapping direction;
mapping cardinality;
confidence scores;
contradiction findings;
rationale;
reason codes;
evidence references.

A representative candidate may look conceptually like:

candidate_mapping:
  source_fragment_ref: <exact-pp-source-fragment>
  requirement_ref: <exact-governed-requirement>

  taxonomy_release_id: <exact-release>
  concept_qname: <exact-qname>
  mapping_role: primary_datapoint

  decision_basis: hybrid
  match_score: 0.97

  reason_codes:
    - SOURCE_REFERENCE_MATCH
    - SEMANTIC_LABEL_ALIGNMENT
    - PERIOD_TYPE_COMPATIBLE
    - DIMENSION_STRUCTURE_COMPATIBLE

  contradictions: []
  rationale: <reviewable explanation>
  classifier_output_digest: <immutable-digest>

10.4 AI-assisted FOGE compilation

After Pergamum semantics and PP-MAP relationships are governed, AI MAY propose FOGE structures such as:

Data Need boundaries;
reusable semantic Data Need candidates;
grain;
dimensions;
cardinality;
completeness rules;
evidence requirements;
derivation possibilities;
estimation constraints;
candidate validation rules;
candidate SSSR signal requirements;
likely interaction strategy;
opportunities for zero-question outcomes.

The distinction SHALL remain:

AI proposes what FOGE may need to look like. Governed Pergamum, PP-MAP, FOGE, SSSR, ZSSR and executor contracts determine what FOGE is permitted to become and how runtime materialization may be routed and executed.

11. FOGE compilation model

For production compilation, FOGE SHALL consume the canonical Pergamum → FOGE transfer unit defined by FOGE-REC: a published Requirement Execution Package, not a free-standing Pergamum Requirement.

Current governance state: FOGE-REC v0.2 assigns the Requirement Execution Package machine schema identity to https://schemas.zayaz.io/foge/requirement-execution-package/0.2.0/requirement-execution-package.schema.json, registers the persistent package type as ARTIF-ADENGINE-REQUIREMENT-EXECUTION-PACKAGE, and uses the constitutional platform fallback identifier type ARTID. No FOGE-specific identifier prefix is invented. Production compilation is therefore structurally satisfiable, but remains fail-closed unless the read-only compilation gate can prove the exact package bytes, current package lifecycle, exact requirement uniqueness, exact Core 2 PP-MAP/PP-MD bytes and current authority, exact derived-inverse origin where applicable, fresh PP-MAP condition/exception state, XBRL correspondence, PP-MD condition state, and fresh PP-RLCPS Rights Gate outcome for the compilation time.

With the schema/artifact/identifier governance decisions now registered, before compiling any requirement from a package FOGE SHALL fail closed unless it has:

resolved the exact registered Requirement Execution Package schema identity;
validated the package against that exact registered machine schema;
resolved the approved canonical package identifier family/format;
verified that the package's package_ref conforms to that canonical identifier contract;
pinned the exact canonical package identity (package_ref) and exact package version;
verified package publication status;
verified content integrity where applicable;
established the requested release/evaluation context;
verified that the package is effective for that context, using its explicit effective period or the deterministically inherited governed effective window defined by FOGE-REC;
verified that the package has not been superseded or otherwise made invalid for that requested release context;
resolved the exact governed Pergamum references; and
pinned the exact requirement version.

A package that remains published and integrity-valid but is outside its effective period, or has been superseded for the requested release context, SHALL be rejected for new production compilation. Historical replay remains pinned to the canonical package identity/version that actually governed the historical release.

FOGE then compiles those package-governed requirement semantics into interaction-independent Data Needs before deciding whether a user needs to be asked anything.

The semantic chain is:

Published Requirement Execution Package
        │
        ├── exact canonical package_ref + package version
        ├── exact registered schema identity + successful validation
        ├── verified publication / integrity state
        ├── effective for requested release context
        ├── not superseded for that context
        └── exact Pergamum requirement version
        │
        ▼
Reusable FOGE Data Need
"what the information means"
        │
        ▼
FOGE Data Need Use
"this exact use in this exact Form Version"
        │
        ├── exact Requirement Execution Package lineage
        ├── exact Pergamum requirement binding
        ├── exact PP-MAP / XBRL binding
        └── exact SSSR resolution binding
        │
        ▼
Compiled FOGE Form Version

The requirement binding answers:

Why is this information required?
What completeness/evidence/methodological rules apply?
Which exact published Requirement Execution Package carried those semantics into FOGE?

The XBRL binding answers:

How is this information represented in the pinned digital taxonomy?

The SSSR binding answers:

Which governed signal identity and resolution path can satisfy this semantic information?

FOGE therefore becomes the meeting point of obligation semantics, digital reporting semantics and runtime data semantics without collapsing them into one object.

Before the compiled definition can rely on the PP-MAP/XBRL binding as authority, the compilation gate SHALL independently validate the referenced PP-MAP admission, exact governed source/target correspondence, authorized mapping direction and exact effective PP-MD purpose authorization. Merely storing the relation or observing an approved mapping state does not establish authority for this specific use.

12. How XBRL improves FOGE table design

Using regulation or methodology alone may produce a valid but underspecified FOGE model.

XBRL can improve that model by revealing:

whether a breakdown is represented as a dimension;
which members belong to the dimension;
whether a concept is abstract or reportable;
expected data type;
duration or instant semantics;
presentation grouping;
definition-network restrictions;
calculation relationships;
validation context;
related supporting concepts;
official digital references.

For example, a requirement might establish:

population    = employees
period        = reporting period
measure       = headcount
breakdown     = gender
scope         = undertaking
completeness  = complete population

The XBRL taxonomy may additionally reveal:

primary concept
exact QName
gender axis
permitted or expected members
period type
presentation location
definition relationships
supporting concepts

FOGE can then compile a stronger semantic structure:

data_need:
  semantic_result: workforce_gender_distribution

  grain:
    subject: undertaking_or_business_unit
    period: reporting_period

  measure:
    concept: headcount
    aggregation: count

  dimensions:
    - gender_category

  completeness:
    population: governed_complete_population

  xbrl_binding:
    taxonomy_release_id: <exact-release>
    primary_concept_qname: <exact-qname>
    dimension_bindings:
      - <exact-axis-and-members>

The regulatory requirement remains controlling for obligation and methodology. XBRL contributes precise digital structure.

13. SSSR closes the resolution-design loop; ZSSR decides routing; executors materialize

Once FOGE has a governed semantic Data Need, SSSR determines the governed design-time resolution capability for that need. The canonical capability values are distinct from later runtime outcomes.

Conceptually:

FOGE Data Need Use
        │
        ▼
SSSR Binding Group
        │
        ├── STORED
        ├── DERIVABLE
        ├── ACQUIRABLE
        └── UNRESOLVED
        │
        ├── UNRESOLVED ──► no executable governed route;
        │                  blocked/manual handling in FOGE
        │
        └── resolvable pinned binding
                    │
                    ▼
      FOGE / SSSR → ZSSR Data Need / Materialization Contract
                    │
                    ▼
                  ZSSR
       produces governed routing decision
                    │
                    ▼
        DaVE Dispatcher / selected executor
         executes/materializes selected route
                    │
                    ▼
        resolution observation
                    │
                    ▼
                  FOGE
   validation + evidence + trust + item state

SSSR describes the governed route. ZSSR decides where the materialization request should go. DaVE Dispatcher and the selected downstream engine, API/connector handler, system agent, human acquisition workflow or other governed executor perform the selected work. ZSSR SHALL NOT be treated as the component that moves data or performs the downstream materialization itself.

This chapter uses the registered FOGE-SSSR contract as the normative owner of the FOGE/SSSR handoff, four capability states and resolution-observation return, and the registered ZSSR component specification as the normative owner of routing behavior and the ZSSR-decision/DaVE-execution boundary.

A DERIVABLE design-time binding may later yield an actually derived runtime value after ZSSR selects a governed compute route and the dispatched compute engine executes it. An ACQUIRABLE binding may later yield an acquired value after ZSSR selects a governed acquisition route and the dispatched connector, agent, human workflow or other executor performs it. Those runtime outcomes SHALL remain runtime state and SHALL NOT be persisted as substitutes for the canonical design-time capability vocabulary.

The execution result SHALL return to FOGE as a resolution observation with the routing/materialization/execution references, value reference where available, provenance and evidence lineage. FOGE then combines that observation with validation, evidence and trust outcomes to determine item state. SSSR, ZSSR and the selected executor SHALL NOT silently mark the underlying Pergamum requirement satisfied merely because a route was selected or executed.

The runtime outcome may therefore be:

valid existing value      → no question
valid derived value       → no question or confirmation
external acquisition      → automated acquisition / governed confirmation
stale or weak evidence    → confirmation / evidence request
unresolved                → Delta Form / manual collection

This is why a FOGE Data Need SHALL exist independently of an interaction Item.

A requirement can be fully represented and satisfied even when the final form asks the user zero questions.

14. XBRL is used at both ends of the lifecycle

Conventional reporting systems often treat XBRL as a final tagging step:

Report
  ↓
Tag report
  ↓
XBRL

ZAYAZ uses XBRL earlier and later.

14.1 Design and compilation time

XBRL contributes to:

semantic reconciliation;
candidate mapping;
Data Need design;
dimensional structure;
validation design;
completeness analysis;
digital reporting preparation.

14.2 Reporting and filing time

The exact governed XBRL coordinates and PP-MAP lineage MAY be reused downstream, but purpose authority is exact, non-transitive and time-of-use specific. Before every downstream semantic traversal or publication transition, the governing gate SHALL freshly re-resolve the exact effective Core 2 PP-MAP/PP-MD and re-evaluate the governed direction, exact purpose, applicable PP-MD conditions, scoped activation context and canonical PP-RLCPS Rights Gate outcome for that exact material use at the time the use is exercised. An earlier compilation-time or filing-time authorization SHALL NOT be cached as authority for a later purpose.

At minimum:

XBRL or iXBRL tagging requires explicit xbrl_tagging purpose authorization at tagging time;
XBRL validation and dimensional validation require explicit xbrl_validation purpose authorization at validation time;
filing-package preparation requires explicit regulatory_filing purpose authorization at filing-preparation time;
external audience-facing publication that relies on the mapping requires a fresh effective Core 2 PP-MD permitting external_publication, with applicable conditions satisfied, plus a fresh canonical PP-RLCPS Rights Gate outcome and the separately governed external-publication authority;
redistribution that relies on the mapping requires a fresh effective Core 2 PP-MD permitting redistribution, with applicable conditions satisfied, plus a fresh canonical PP-RLCPS Rights Gate outcome and the separately governed redistribution authority;
foge_compilation SHALL NOT imply any downstream purpose;
regulatory_filing SHALL NOT imply external publication or redistribution; and
external_publication SHALL NOT imply redistribution.

Subject to those fresh gates, the same exact governed coordinates may support:

XBRL tagging;
iXBRL generation;
validation;
dimensional consistency;
taxonomy-release pinning;
filing-package preparation;
replay and audit.

Conceptually:

XBRL Taxonomy
      │
      ▼
Pergamum semantic reconciliation
      │
      ▼
FOGE compilation
      │
      ▼
SSSR resolution binding
      │
      ▼
ZSSR routing decision
      │
      ▼
DaVE Dispatcher / selected executor
      │
      ▼
Governed ESG outcome
      │
      ▼
Report / disclosure
      │
      ▼
Same exact governed XBRL coordinates
+ fresh purpose / conditions / PP-RLCPS Rights Gate / activation gate
      │
      ▼
Validation / tagging / filing preparation

This creates a closed semantic loop from regulatory understanding to digital reporting without allowing one lifecycle purpose to silently authorize another.

15. Current physical foundation in ZAYAZ

The current implementation foundation already separates these responsibilities.

15.1 XBRL custody and projection

Pergamum Pulse persists the registered technical taxonomy foundation through structures including:

pp.xbrl_taxonomy_release
pp.xbrl_taxonomy_file
pp.xbrl_concept
pp.xbrl_relationship

These preserve exact release identity, provenance and queryable digital semantics without converting XBRL into legal authority.

15.2 Candidate source-fragment mapping

Candidate reconciliation is represented through:

pp.source_fragment_xbrl_mapping

The candidate model supports decision bases including:

taxonomy_reference
deterministic_rule
ai
hybrid

Candidate status is distinct from admitted PP-MAP authority.

15.3 Pergamum-to-FOGE requirement binding

FOGE pins exact requirement semantics through:

core_relations.foge_pergamum_data_need_bindings

This preserves why a Data Need is required and which exact Pergamum object version governs it. Production compilation still enters FOGE through the published Requirement Execution Package boundary defined by FOGE-REC; the physical requirement binding does not replace canonical package identity, package schema registration/validation, publication, integrity, effective-period, supersession, version-pinning or provenance obligations. FOGE-REC v0.2, ARTIF-ADENGINE-REQUIREMENT-EXECUTION-PACKAGE, and ARTID are now registered governance. Production therefore fails closed only when the concrete package instance, exact package bytes, lifecycle state, or a later compilation-time authority predicate cannot be affirmatively resolved.

15.4 FOGE-to-XBRL binding

FOGE structurally pins the PP-MAP reference and exact XBRL taxonomy coordinates through:

core_relations.foge_data_need_xbrl_bindings

The current physical table verifies that the referenced mapping object/version exists in pp.object_version, requires a PP-MAP- identifier shape, and pins the exact taxonomy release and QName. This is valuable structural integrity and prevents a floating "latest" taxonomy concept.

It does not, by itself, prove that the referenced PP-MAP has completed governed admission, that an approving Mapping Decision exists, that the PP-MAP source side is the exact Pergamum requirement bound to this Data Need Use, that the PP-MAP target side is the exact taxonomy release/QName stored in the FOGE binding, that the mapping direction authorizes requirement-to-XBRL traversal, or that the Mapping Decision permits the intended FOGE purpose.

Therefore:

A row in core_relations.foge_data_need_xbrl_bindings is not, on its own, evidence of PP-MAP admission or purpose-authorized use.

Before a FOGE definition may treat the XBRL relationship as approved semantic authority, a separate governed validation gate SHALL resolve the exact PP-MAP and exact PP-MD through canonical Pergamum mapping governance and verify at least:

the exact PP-MAP version declares the PP-SMCS Core 2.0 Mapping Object schema identity when v0.2 direction semantics are relied upon;
the exact PP-MD version declares the PP-SMCS Core 2.0 Mapping Decision schema identity when v0.2 purpose semantics are relied upon;
a historical Core 1 PP-MAP or PP-MD is not treated as Core 2-conformant merely because its values resemble the Core 2 vocabulary; governed migration must produce Core 2-conformant successor versions first;
admitted/approved mapping state under the applicable mapping decision;
exact mapping object ID and version;
exact PP-MD identity and version bound to that exact PP-MAP;
PP-MD decision state is currently effective and suitable for use;
exact governed source identity and version;
correspondence to the Pergamum requirement bound to the same Data Need Use;
exact target taxonomy release and QName;
governed mapping type;
governed mapping direction through the canonical Mapping Direction Registry;
proof that the direction authorizes the intended Pergamum-requirement → XBRL-target traversal;
governed mapping cardinality;
PP-MD permitted_purposes explicitly authorize the exact foge_compilation purpose for this compilation use;
PP-MD prohibited_purposes do not prohibit foge_compilation;
all PP-MD conditions applicable to foge_compilation are satisfied at compilation time;
applicable conditions, scope and temporal validity;
mapping and provenance digests where defined.

Approval for internal analysis SHALL NOT be treated as approval for FOGE compilation, FOGE definition publication, Runtime use or external Publication. Purpose authorization SHALL be checked against the exact intended use at the time that use is exercised.

Compilation authorization SHALL NOT be reused as FOGE definition-publication authority. Immediately before publishing a compiled FOGE definition that relies on this mapping, the publication gate SHALL freshly re-resolve the exact effective Core 2 PP-MAP/PP-MD, re-prove the governed requirement-to-XBRL traversal, require explicit foge_definition_publication purpose authorization, re-evaluate all PP-MD conditions applicable to that purpose, and obtain a canonical PP-RLCPS Rights Gate outcome permitting that exact publication use. Any expired, revoked, superseded, prohibited, unresolved or otherwise non-authorizing state at publication time SHALL fail closed.

Any mismatch, unauthorized direction, unauthorized purpose or unresolved admission state SHALL fail closed for the material use being exercised.

This is an intentional distinction between structural persistence enforcement and semantic/governance admission enforcement. Future database or compiler hardening MAY make more of these admission checks structurally enforceable, but documentation SHALL NOT describe the present table as enforcing guarantees it does not yet enforce.

15.5 FOGE-to-SSSR binding, ZSSR routing and dispatched execution

FOGE resolves semantic Data Needs toward canonical runtime signals through the governed SSSR binding structures associated with each Data Need Use. SSSR preserves the signal identity and governed route description. At runtime, a resolvable pinned binding is handed through the FOGE/SSSR → ZSSR Data Need / Materialization Contract; ZSSR produces the governed routing decision, while DaVE Dispatcher and the selected downstream executor perform the route/materialization. The resulting resolution observation returns to FOGE.

Together these form the physical and execution lineage:

Published Requirement Execution Package
        │
        └── exact Pergamum requirement/version
                │
                ▼
        foge_pergamum_data_need_bindings
                │
                ▼
        FOGE Data Need Use
                │
                ├── foge_data_need_xbrl_bindings
                │       └── PP-MAP reference → exact XBRL release/QName
                │           + independent PP-MAP admission validation
                │           + Core 2 identity validation for v0.2 semantics
                │           + direction authorization
                │           + exact PP-MD purpose authorization
                │
                └── SSSR binding groups
                        └── exact governed signal identity + route description
                                │
                                ▼
                        FOGE / SSSR → ZSSR handoff
                                │
                                ▼
                         ZSSR routing decision
                                │
                                ▼
                     DaVE Dispatcher / selected executor
                                │
                                ▼
                         resolution observation
                                │
                                └──► FOGE runtime state/projection

16. Capability-specific XBRL authority

XBRL lifecycle state SHALL not be represented by one global Boolean such as active=true.

ZAYAZ SHOULD distinguish capabilities such as:

registered
semantic_analysis
mapping_candidate_generation
foge_compilation
xbrl_validation
xbrl_tagging
regulatory_filing
customer_display
public_api
external_report_publication
redistribution

These labels describe capability scopes in this architecture; they do not create a new governed vocabulary merely by appearing in this document. Where a label is also a PP-SMCS Core 2 Mapping Purpose identifier, the PP-MD meaning and authority boundary are owned by PP-SMCS rather than by this capability illustration.

A taxonomy may be eligible for one capability and prohibited for another.

For example:

registered                  YES
internal semantic analysis  YES, if rights permit
candidate mapping           YES, if rights permit
FOGE compilation            YES only when the exact registered package instance/version/bytes, current lifecycle, admitted Core 2 mapping/decision, XBRL coordinates, conditions and fresh Rights Gate evidence all authorize the exact compilation use
runtime validation          only after scoped runtime activation
customer display            separate authority
external report publication separate authority
redistribution              separate rights authority

FOGE's own publication of immutable compiled definition versions is a separate FOGE lifecycle concern and is not the external_report_publication capability described above.

This capability-scoped model prevents registration, analysis, runtime use and external publication from being accidentally collapsed.

17. Rights and temporal controls

Semantic usefulness does not override rights.

Every material use governed by this architecture SHALL pass the canonical PP-RLCPS Rights Gate for that exact use. The gate SHALL evaluate all applicable Rights Records, Rights Decisions and supporting rights evidence together; inspection of one PP-RGT, one Rights Decision or a reduced local checklist SHALL NOT be treated as equivalent authority.

The Rights Gate outcome SHALL be evaluated for the exact intended use and applicable context, including at minimum the PP-RLCPS-governed inputs for source/object identity, purpose, audience, territory, channel, duration, processing type, publication type, licence, agreement, attribution, confidentiality, tenant scope, white-label scope, expiration, revocation and provenance. Where multiple applicable Rights Records or inherited restrictions exist, the canonical PP-RLCPS precedence and gate semantics apply.

A material use SHALL remain blocked unless its canonical Rights Gate outcome permits that exact use, including satisfaction of any conditions. Outcomes requiring legal review, additional permission, quarantine, blocking or an unable-to-determine state SHALL NOT be converted into runtime, compilation, publication or redistribution authority by this chapter.

A taxonomy may therefore be technically registered and semantically valuable while still being blocked for compilation, runtime or customer-facing use. Runtime activation and every later material use SHALL preserve this distinction and SHALL obtain a fresh Rights Gate outcome where the intended use, audience, channel, scope, time or rights evidence changes.

18. Provenance and replay

Every material mapping and compiled FOGE release SHOULD be independently reconstructible.

At minimum, provenance SHOULD retain:

exact regulation/methodology source object and version;
exact published Requirement Execution Package identity and version used for FOGE compilation;
exact ARTID registry resolution used to validate the package identity;
exact registered FOGE-REC v0.2 Requirement Execution Package schema identity/version used for validation;
package publication, effective-period, supersession and integrity evidence required by FOGE-REC;
exact source fragment or governed requirement identity and version within that package;
source capture and evidence lineage;
exact PP-MAP object and version;
exact PP-MD identity and version used to authorize the mapping purpose;
exact XBRL taxonomy release;
exact QName(s);
mapping type, direction and cardinality;
dimensional and role context;
candidate-analysis output digest where applicable;
AI model/profile/run evidence where AI materially contributed;
FOGE Form Version;
FOGE Data Need Version;
exact Data Need Use;
exact SSSR binding group/version;
exact ZSSR routing decision reference where runtime routing occurred;
exact DaVE/downstream materialization or execution reference where work executed;
runtime context and effective time for execution;
downstream validation/tagging binding;
Module lineage;
Component lineage.

Historical replay SHALL use the versions that were actually governed and compiled, including the exact Requirement Execution Package identity/version under its canonical identifier contract, the exact Core 2 PP-MAP/PP-MD versions used for v0.2 direction/purpose authority, and the exact purpose-authorizing PP-MD decision—not whatever package, taxonomy, model, mapping decision or requirement is currently latest.

19. AI provenance requirements

Where AI contributes materially, the review package SHOULD preserve enough information to reproduce or audit the analytical claim without treating hidden model state as authority.

Evidence may include:

model family and governed Model Profile;
prompt/profile version;
retrieval/context package identity;
source-fragment identities;
taxonomy release and concepts considered;
deterministic feature evidence;
candidate ranking;
confidence score;
reason codes;
contradictions detected;
rationale;
output digest;
HECATE validation result;
reviewer decision;
admitted PP-MAP identity where approved;
exact PP-MD identity/version and purpose authorization where the mapping is consumed downstream.

The durable authority is the governed outcome and its evidence chain, not the fact that an AI system produced a confident answer.

20. Validation and contradiction checks

Before a mapping can support governed FOGE production compilation, caller-supplied sidecars SHALL NOT be treated as evidence merely because they contain digest-shaped values or affirmative booleans. The compilation gate SHALL require a trusted evidence authority outside the caller-controlled input to resolve each evidence reference and authenticate an immutable context digest for package schema validation, identifier and lifecycle resolution, PP-MAP/PP-MD validation and current-state resolution, admission, conditional-purpose resolution, XBRL binding/correspondence and the PP-RLCPS Rights Gate.

Before a mapping can support governed FOGE production compilation, validation SHALL first establish that the exact package bytes validate against the FOGE-REC v0.2 machine schema https://schemas.zayaz.io/foge/requirement-execution-package/0.2.0/requirement-execution-package.schema.json and that its package_ref resolves as an ARTID instance of registered artifact type ARTIF-ADENGINE-REQUIREMENT-EXECUTION-PACKAGE. These governance prerequisites now exist; production still fails closed whenever the concrete registry resolution, package lifecycle resolution, or any downstream authority proof is absent or non-authorizing.

Validation SHALL then test at least:

the exact registered Requirement Execution Package schema identity/version is resolved;
the Requirement Execution Package has been validated against that exact registered machine schema;
the approved canonical package identifier family/format is resolved;
the exact package_ref conforms to that canonical identifier contract;
the exact canonical package identity and package version are pinned for compilation and replay;
package publication status and content integrity have been verified as required by FOGE-REC;
the requested release/evaluation context is established;
the package's explicit or deterministically inherited governed effective period includes that requested context;
the package has not been superseded or otherwise made invalid for that requested release context;
the exact Pergamum requirement version is pinned for compilation and replay;
requirement identity is admitted and exact-version pinned within that governed package context;
XBRL taxonomy release is registered and exact-version pinned;
XBRL concept exists in that release;
referenced PP-MAP object/version exists;
the exact PP-MAP version is Core 2-conformant before PP-SMCS v0.2 direction semantics are used;
exact PP-MD identity/version exists and is bound to that exact PP-MAP;
the exact PP-MD version is Core 2-conformant before PP-SMCS v0.2 purpose semantics are used;
historical Core 1 PP-MAP/PP-MD versions are not interpreted under Core 2; governed migration must create Core 2-conformant successor versions before v0.2 automation depends on them;
PP-MAP has the required governed admission/approval state under that PP-MD;
PP-MD decision state is approved or approved-with-conditions as applicable, is effective at evaluation time, is not expired, revoked or superseded for the intended use, and all applicable conditions are satisfied;
PP-MAP source identity/version corresponds to the exact Pergamum requirement bound to the same Data Need Use;
PP-MAP target identity/version or target reference corresponds to the exact XBRL taxonomy release and QName pinned by the FOGE binding;
mapping type resolves through the canonical Pergamum Pulse Mapping Type Registry;
mapping direction resolves through the canonical Pergamum Pulse Mapping Direction Registry;
the exact source/target orientation plus governed direction authorize traversal from the Pergamum requirement to the XBRL target for this use;
mapping cardinality resolves through the canonical Pergamum Pulse Mapping Cardinality Registry;
PP-MD permitted_purposes explicitly permit the exact foge_compilation purpose for the compilation use currently being exercised;
PP-MD prohibited_purposes do not prohibit foge_compilation;
approval for internal analysis is not treated as approval for FOGE compilation, FOGE definition publication, Runtime use or external Publication;
mapping role is valid;
semantic grain is compatible;
dimensions are compatible;
period semantics are compatible;
data type is compatible;
units or unit constraints are compatible where applicable;
methodological constraints do not contradict the XBRL interpretation;
required population is not weakened;
derivation policy is preserved;
estimation policy is preserved;
evidence requirements are preserved;
the canonical PP-RLCPS Rights Gate has evaluated all applicable rights records/evidence for this exact material use and its outcome permits the intended processing capability, with all required conditions satisfied;
applicable temporal scopes overlap;
no ambiguous competing mapping is silently selected.

The structural constraints on core_relations.foge_data_need_xbrl_bindings SHALL NOT be used as a substitute for these Requirement Execution Package, PP-MAP admission, Core 2 identity, direction, PP-MD purpose or correspondence checks.

A package that does not validate against the exact FOGE-REC v0.2 machine schema, or whose package identifier cannot be affirmatively resolved through the canonical identifier registry, SHALL always fail closed for production compilation; governed review SHALL NOT override either prerequisite. A Requirement Execution Package that is outside its effective period, has been superseded, or is otherwise invalid for the requested release context SHALL likewise be rejected for new production compilation without a governed-review override.

Once those package prerequisites are satisfied, a determined authorization failure SHALL also fail closed and SHALL NOT be overridden by governed review. This includes a Core-version mismatch where Core 2 semantics are required, an ineffective/revoked/superseded PP-MD for the intended use, a governed direction that does not authorize the requested traversal, a missing or prohibited required purpose, or an established source/target identity mismatch. Governed review MAY be used only where evidence remains incomplete, ambiguous or contradictory before an authorization determination—for example unresolved admission evidence, unresolved semantic correspondence or competing candidate mappings. If governed review results in a corrected, migrated, superseding or newly approved governed artifact/version, the complete gate SHALL be re-evaluated against that resulting artifact/version; review SHALL NOT waive the failed predicate on the original artifact/version.

FOGE definition publication, downstream XBRL validation, tagging, filing preparation, external publication and redistribution SHALL each perform their own fresh exact-purpose authorization check at the time that purpose is exercised. Each such gate SHALL re-resolve the exact effective Core 2 PP-MAP/PP-MD, re-evaluate governed direction and applicable PP-MD conditions, and obtain the canonical PP-RLCPS Rights Gate outcome required for that exact material use. Successful compilation or any earlier lifecycle purpose SHALL NOT be treated as inherited authority for a later purpose. External publication and redistribution additionally remain subject to their separate publication/redistribution authority beyond mapping-purpose and rights authorization.

21. Failure modes and prohibited shortcuts

21.1 XBRL-first obligation inference

Prohibited: treating every XBRL concept as a legal disclosure requirement.

Correct: use admitted Pergamum requirements to determine obligation and applicability; use XBRL for digital semantics.

21.2 Prose-only FOGE compilation

Risk: valid legal interpretation but weak digital structure, missed dimensions or reporting relationships.

Correct: reconcile the requirement with the relevant registered XBRL taxonomy where such taxonomy exists and is permitted for the intended purpose.

21.3 AI auto-approval

Prohibited: high confidence automatically creates PP-MAP authority.

Correct: AI output remains candidate evidence until governed admission.

21.4 Floating taxonomy concepts

Prohibited: bind FOGE to "latest ESRS concept".

Correct: pin exact taxonomy release + exact QName + exact PP-MAP version.

21.5 Requirement collapse into UI

Prohibited: assume one legal requirement equals one question.

Correct: compile semantic Data Needs first. Runtime resolution determines whether any question is needed.

21.6 Requirement collapse into XBRL

Prohibited: replace Pergamum requirement semantics with taxonomy metadata.

Correct: preserve both and connect them through governed mapping.

21.7 Runtime data written back as requirement meaning

Prohibited: tenant evaluation results mutate the immutable requirement package.

Correct: requirement meaning remains context-independent; runtime applicability and satisfaction are separate outcomes.

21.8 Registration implies runtime use

Prohibited: a registered taxonomy is automatically considered available for all runtime consumers.

Correct: runtime activation is capability-, scope-, tenant-, environment- and time-specific.

21.9 Binding persistence treated as mapping admission

Prohibited: assume that a foge_data_need_xbrl_bindings row proves that the referenced PP-MAP is approved merely because the foreign key resolves and the object ID begins with PP-MAP-.

Correct: validate PP-MAP admission plus exact governed source/target correspondence before the binding can support governed FOGE compilation or definition publication.

21.10 Admission treated as universal traversal or purpose authority

Prohibited: assume that an admitted PP-MAP may be traversed from requirement to XBRL regardless of its governed direction, or that an approving PP-MD for internal analysis automatically authorizes FOGE compilation or definition publication.

Correct: resolve the canonical mapping direction and prove that the intended requirement-to-XBRL traversal is authorized; then resolve the exact effective PP-MD and prove that its permitted/prohibited purposes and conditions authorize the exact intended FOGE use. If either authorization predicate fails, the use remains blocked; governed review cannot waive the failed direction or purpose on that artifact/version.

21.11 Free-standing requirement compilation

Prohibited: compile a production FOGE definition directly from an individually admitted Pergamum Requirement while bypassing the Requirement Execution Package identity, schema, publication, integrity and version-pinning boundary.

Correct: consume the published Requirement Execution Package defined by FOGE-REC under the registered ARTIF-ADENGINE-REQUIREMENT-EXECUTION-PACKAGE type and ARTID identifier contract; validate its canonical package_ref, validate the exact package bytes against the registered v0.2 schema, prove current lifecycle/effective/supersession state externally to the immutable bytes, require exactly one matching requirement identity/version, and pin the exact package identity/version/digest before compilation.

21.12 Earlier purpose authority reused for a later lifecycle transition

Prohibited: carry foge_compilation authorization into FOGE definition publication, XBRL validation, tagging or filing preparation, or carry regulatory_filing or any other earlier purpose into external publication or redistribution without a fresh exact-purpose check.

Correct: at the moment each purpose is exercised, freshly re-resolve the exact effective Core 2 PP-MAP/PP-MD, prove the governed traversal, independently authorize foge_definition_publication, xbrl_validation, xbrl_tagging, regulatory_filing, external_publication or redistribution as applicable, satisfy all conditions for that purpose, obtain a fresh canonical PP-RLCPS Rights Gate outcome, and preserve any separately governed activation, publication or redistribution authority.

21.13 Published package treated as automatically current

Prohibited: accept a package for a new production release merely because it remains published and integrity-valid.

Correct: prove that the package is effective for the requested release/evaluation context and has not been superseded or otherwise invalidated for that context; otherwise fail closed.

21.14 ZSSR treated as materialization executor

Prohibited: make ZSSR itself perform derivation, acquisition or other materialization merely because it selects the governed route.

Correct: hand the pinned FOGE/SSSR materialization need to ZSSR for a governed routing decision; then DaVE Dispatcher and the selected downstream executor perform the route/materialization and return the resulting resolution observation to FOGE.

21.15 Unregistered Requirement Execution Package contract identities treated as executable

Prohibited: claim production FOGE compilation readiness using an inferred, local or unregistered Requirement Execution Package schema identity, machine schema, package identifier family/format or package_ref.

Correct: the governed identities are the registered FOGE-REC v0.2 schema, ARTIF-ADENGINE-REQUIREMENT-EXECUTION-PACKAGE, and ARTID. Any inferred or local substitute remains non-authoritative, and the production path remains fail-closed whenever exact registry resolution or any fresh compilation-time authority proof is unavailable.

21.16 Governed review treated as an authorization override

Prohibited: use governed review to waive a failed Core-version, mapping-direction, PP-MD purpose, effective-decision or exact source/target authorization predicate for the artifact/version under evaluation.

Correct: use governed review only to resolve evidence that is incomplete, ambiguous or contradictory before an authorization determination. If review produces a corrected, migrated, superseding or newly approved governed artifact/version, evaluate the complete gate again against that resulting artifact/version.

21.17 Rights record inspection treated as Rights Gate authority

Prohibited: authorize compilation, activation, validation, tagging, filing preparation, publication or redistribution by checking only one PP-RGT, one Rights Decision or a reduced subset of rights fields.

Correct: every material use must pass the canonical PP-RLCPS Rights Gate over all applicable rights records, decisions and supporting evidence for the exact use/context. Any blocking, legal-review, additional-permission, quarantine or unable-to-determine outcome remains non-authorizing until PP-RLCPS governance produces a permitting gate outcome.

22. Architectural responsibility matrix

Concern	Pergamum Pulse	XBRL layer	PP-MAP	FOGE	SSSR	ZSSR	DaVE / selected executor	AI
Legal/methodological requirement meaning	Owns	Does not own	Does not create	Consumes	Does not own	Does not own	Does not own	Assists only
Applicability semantics	Owns	May provide supporting digital context	May relate	Consumes	Does not own	Does not own	Does not own	Assists only
Digital reporting concept identity	Preserves	Owns provider semantics	Bridges	Pins	Does not own	Does not own	Does not own	Discovers candidates
Regulation ↔ XBRL semantic correspondence	Provides source side	Provides taxonomy side	Admitted bridge with governed direction	Consumes only after admission, direction and purpose validation	Does not own	Does not own	Does not own	Proposes / tests
FOGE Data Need meaning	Provides requirement semantics	Supports structure	Supports exact digital binding	Owns compiled Data Need model	Consumes semantic need for signal binding	Routes only after governed handoff	Executes only selected materialization work	Proposes
Signal discovery / resolution path	Does not own	Does not own	Does not own	Requests and pins	Owns governed signal identity, discovery and route description	Consumes pinned route	Consumes dispatched execution request	May assist discovery
Runtime routing decision	Does not own	Does not own	Does not own	Requests and consumes observation	Describes route; does not decide runtime destination	Owns governed routing decision / hint	Executes dispatched route; does not redefine routing authority	Never grants authority
Runtime materialization / acquisition / computation	Does not own	Does not own	Does not own	Consumes observation	Does not execute	Does not move data or execute materialization	Owns dispatched execution in the selected engine/workflow context	Never grants authority
Interaction strategy	Does not own UI	Does not own	Does not own	Owns	Supplies binding semantics	Supplies routing decision	Returns runtime observations	May propose
FOGE definition publication	Mapping decision may constrain permitted use	Does not own	PP-MD must authorize use; PP-MAP alone does not grant it	Owns publication and immutability rules for its compiled framework/Form/Data Need/Item definitions	Does not own	Does not own	Does not own	Never grants
Runtime activation	Evidence input only unless otherwise governed	Subject of activation	Does not imply activation	Consumes resolved runtime authority	Resolution metadata may constrain	Routes only under resolved authority	Executes only under dispatched/resolved authority	Never grants
External customer/report/taxonomy publication and redistribution	Rights/governance evidence may constrain	Does not grant	Does not grant	FOGE definition publication does not grant this authority	Does not grant	Does not grant	Does not grant	Never grants

23. Reference example — semantic triangle

The following conceptual example demonstrates the intended relationship without asserting a specific production-admitted ESRS mapping.

Regulation / methodology says:

"Provide workforce headcount distributed by gender for the
applicable reporting population."

            │
            ▼
Pergamum Requirement Semantics
            │
            ▼
Published Requirement Execution Package
(exact canonical package_ref + package version,
validated against the registered FOGE-REC v0.2 package schema,
identity-governed through the registered `ARTID` contract,
effective and non-superseded for requested release context)

population      governed workforce population
measure         headcount
period          reporting period
breakdown       gender
completeness    complete governed population
derivation      governed policy
estimation      governed policy

            +

XBRL digital semantics indicate:

primary concept     candidate exact QName
gender axis         candidate exact QName
members             candidate exact QNames
period type         duration
network context     presentation / definition relationships

            │
            ▼
AI + deterministic reconciliation

canonical mapping_type + mapping direction + mapping cardinality
+ diagnostic compatibility / contradiction findings
            │
            ▼
Governed Core 2 PP-MAP admission
+ exact Core 2 PP-MD purpose authorization
            │
            ▼
FOGE Data Need Use

workforce_gender_distribution
+ exact Requirement Execution Package lineage
+ exact Pergamum requirement binding
+ exact XBRL semantic binding
+ exact SSSR signal binding / resolution path
            │
            ▼
FOGE / SSSR → ZSSR materialization handoff
            │
            ▼
ZSSR produces governed routing decision
            │
            ▼
DaVE Dispatcher / selected downstream executor performs work
            │
            ▼
resolution observation returns to FOGE
            │
            ▼
Runtime projection

valid governed signal? ── yes ──► zero questions / confirmation as governed
            │
            no / unresolved
            ▼
Delta Form / evidence request / acquisition workflow

The value of the architecture is not merely better tagging. It is better requirement execution.

The production path illustrated above now has governed FOGE-REC v0.2 schema, artifact and ARTID identity registration plus an executable read-only compilation-authority gate. It remains fail-closed per execution until the concrete package instance and every package/admission/lifecycle/mapping/decision/XBRL/rights evidence reference are resolved through the trusted evidence authority and authenticate the exact context being compiled.

24. Strategic value for ZAYAZ

This architecture allows ZAYAZ to move beyond the common ESG-platform pattern of hard-coded questionnaires and late-stage tagging.

It enables:

regulation-aware and methodology-aware Data Needs;
taxonomy-aware FOGE structures;
exact requirement-to-digital-reporting lineage;
AI-assisted semantic reconciliation at scale;
explicit contradiction detection;
reusable PP-MAP authority;
exact-version replay;
lower manual mapping cost;
stronger filing readiness;
stronger automated validation;
fewer unnecessary user questions;
better SSSR prefill and derivation opportunities;
governed ZSSR runtime routing decisions without moving materialization execution into the router;
dispatcher/executor separation for governed computation and acquisition;
explainable differences between legal meaning and digital taxonomy representation;
scalable support for future taxonomy releases and additional reporting frameworks;
white-label and tenant-specific runtime activation without corrupting global canonical semantics.

The architecture also creates a foundation for future cross-framework intelligence. A governed semantic Data Need may be reused across several requirements while each requirement retains its own authority, evidence and reporting bindings.

25. Governing summary

The architecture can be summarized as:

REGULATION / METHODOLOGY
        │
        │ legal + methodological authority
        ▼
PERGAMUM PULSE
        │
        ▼
PUBLISHED REQUIREMENT EXECUTION PACKAGE
 canonical package identity + schema governed before production use
 effective + non-superseded for release context
        │
        │ governed requirements and Data Need semantics
        │
        ├─────────────────────────────┐
        │                             │
        ▼                             ▼
   SOURCE SEMANTICS              XBRL SEMANTICS
                                      │
                          concepts + dimensions + networks
        │                             │
        └──────────────┬──────────────┘
                       ▼
               AI / DETERMINISTIC
              CANDIDATE RECONCILIATION
                       │
                       ▼
                     PP-MAP
              admitted semantic bridge
                       │
                       ▼
                      FOGE
              governed interaction compiler
                       │
                       ▼
                      SSSR
       signal identity + governed route description
                       │
                       ▼
                      ZSSR
          governed runtime routing decision
                       │
                       ▼
          DAVE / SELECTED EXECUTOR
        dispatched materialization/execution
                       │
                       ▼
           RESOLUTION OBSERVATION TO FOGE
                       │
                       ▼
            COMPLETE / DELTA INTERACTION
                       │
                       ▼
               GOVERNED ESG OUTCOME
                       │
                       ▼
        XBRL VALIDATION / TAGGING / FILING
     each through a fresh exact-purpose gate
                       │
                       ▼
             REPORTING / PUBLICATION
             through separate authority

Current production-readiness boundary: the FOGE-REC v0.2 schema, ARTIF-ADENGINE-REQUIREMENT-EXECUTION-PACKAGE, and ARTID are governed in-repository. Production compilation is therefore no longer categorically unavailable at package identity admission; it remains fail-closed per execution unless the exact package instance/version/bytes and current lifecycle resolve successfully and every Core 2 mapping, purpose, condition, rights, and XBRL correspondence predicate authorizes that exact use.

The final governing rule is:

ZAYAZ SHALL use regulation and methodology to preserve obligation meaning, XBRL to preserve exact digital-reporting semantics, AI to accelerate semantic discovery and reconciliation, PP-MAP to establish governed correspondence, a canonical-identity-and-schema-governed, effective and context-valid published Requirement Execution Package to transfer executable requirement semantics into FOGE, FOGE to compile executable information needs, SSSR to govern signal identity and describe resolution routes, ZSSR to produce governed routing decisions, and DaVE Dispatcher plus the selected downstream executor to perform materialization and return resolution observations to FOGE. No layer SHALL silently inherit authority from another merely because the layers are technically connected.

GitHub Repo Request for Change (RFC)

1. Purpose​

2. Core constitutional invariants​

2.1 XBRL does not create the legal requirement​

2.2 Regulation does not define physical data location​

2.3 AI does not create authority​

2.4 PP-MAP is a governed bridge, not a guess​

2.5 FOGE does not reinterpret source law at runtime​

2.6 SSSR describes governed resolution; ZSSR decides routing; executors materialize​

2.7 Activation, definition publication, external publication and legal authority remain separate​

3. The three semantic planes​

4. End-to-end architecture​

5. Pergamum regulation and methodology semantics​

6. XBRL as a digital semantic graph​

7. PP-MAP as the reconciliation authority​

8. Candidate reconciliation before PP-MAP admission​

8.1 Deterministic evidence​

8.2 Semantic evidence​

8.3 Hybrid evidence​

9. Canonical reconciliation dimensions and diagnostic findings​

9.1 Mapping type​

9.2 Mapping direction​

9.3 Mapping cardinality​

9.4 Diagnostic findings remain separate from mapping identity​

10. AI role​

10.1 AI-assisted source interpretation​

10.2 AI-assisted XBRL interpretation​

10.3 AI-assisted semantic reconciliation​

10.4 AI-assisted FOGE compilation​

11. FOGE compilation model​

12. How XBRL improves FOGE table design​

13. SSSR closes the resolution-design loop; ZSSR decides routing; executors materialize​

14. XBRL is used at both ends of the lifecycle​

14.1 Design and compilation time​

14.2 Reporting and filing time​

15. Current physical foundation in ZAYAZ​

15.1 XBRL custody and projection​

15.2 Candidate source-fragment mapping​

15.3 Pergamum-to-FOGE requirement binding​

15.4 FOGE-to-XBRL binding​

15.5 FOGE-to-SSSR binding, ZSSR routing and dispatched execution​

16. Capability-specific XBRL authority​

17. Rights and temporal controls​

18. Provenance and replay​

19. AI provenance requirements​

20. Validation and contradiction checks​

21. Failure modes and prohibited shortcuts​

21.1 XBRL-first obligation inference​

21.2 Prose-only FOGE compilation​

21.3 AI auto-approval​

21.4 Floating taxonomy concepts​

21.5 Requirement collapse into UI​

21.6 Requirement collapse into XBRL​

21.7 Runtime data written back as requirement meaning​

21.8 Registration implies runtime use​

21.9 Binding persistence treated as mapping admission​

21.10 Admission treated as universal traversal or purpose authority​

21.11 Free-standing requirement compilation​

21.12 Earlier purpose authority reused for a later lifecycle transition​

21.13 Published package treated as automatically current​

21.14 ZSSR treated as materialization executor​

21.15 Unregistered Requirement Execution Package contract identities treated as executable​

21.16 Governed review treated as an authorization override​

21.17 Rights record inspection treated as Rights Gate authority​

22. Architectural responsibility matrix​

23. Reference example — semantic triangle​

24. Strategic value for ZAYAZ​

25. Governing summary​

1. Purpose

2. Core constitutional invariants

2.1 XBRL does not create the legal requirement

2.2 Regulation does not define physical data location

2.3 AI does not create authority

2.4 PP-MAP is a governed bridge, not a guess

2.5 FOGE does not reinterpret source law at runtime

2.6 SSSR describes governed resolution; ZSSR decides routing; executors materialize

2.7 Activation, definition publication, external publication and legal authority remain separate

3. The three semantic planes

4. End-to-end architecture

5. Pergamum regulation and methodology semantics

6. XBRL as a digital semantic graph

7. PP-MAP as the reconciliation authority

8. Candidate reconciliation before PP-MAP admission

8.1 Deterministic evidence

8.2 Semantic evidence

8.3 Hybrid evidence

9. Canonical reconciliation dimensions and diagnostic findings

9.1 Mapping type

9.2 Mapping direction

9.3 Mapping cardinality

9.4 Diagnostic findings remain separate from mapping identity

10. AI role

10.1 AI-assisted source interpretation

10.2 AI-assisted XBRL interpretation

10.3 AI-assisted semantic reconciliation

10.4 AI-assisted FOGE compilation

11. FOGE compilation model

12. How XBRL improves FOGE table design

13. SSSR closes the resolution-design loop; ZSSR decides routing; executors materialize

14. XBRL is used at both ends of the lifecycle

14.1 Design and compilation time

14.2 Reporting and filing time

15. Current physical foundation in ZAYAZ

15.1 XBRL custody and projection

15.2 Candidate source-fragment mapping

15.3 Pergamum-to-FOGE requirement binding

15.4 FOGE-to-XBRL binding

15.5 FOGE-to-SSSR binding, ZSSR routing and dispatched execution

16. Capability-specific XBRL authority

17. Rights and temporal controls

18. Provenance and replay

19. AI provenance requirements

20. Validation and contradiction checks

21. Failure modes and prohibited shortcuts

21.1 XBRL-first obligation inference

21.2 Prose-only FOGE compilation

21.3 AI auto-approval

21.4 Floating taxonomy concepts

21.5 Requirement collapse into UI

21.6 Requirement collapse into XBRL

21.7 Runtime data written back as requirement meaning

21.8 Registration implies runtime use

21.9 Binding persistence treated as mapping admission

21.10 Admission treated as universal traversal or purpose authority

21.11 Free-standing requirement compilation

21.12 Earlier purpose authority reused for a later lifecycle transition

21.13 Published package treated as automatically current

21.14 ZSSR treated as materialization executor

21.15 Unregistered Requirement Execution Package contract identities treated as executable

21.16 Governed review treated as an authorization override

21.17 Rights record inspection treated as Rights Gate authority

22. Architectural responsibility matrix

23. Reference example — semantic triangle

24. Strategic value for ZAYAZ

25. Governing summary