FOGE-M2M
FOGE Data Need and Many-to-Many Signal Binding Model
Version: 0.1.0
Status: Architectural model
Scope: FOGE design/governance-time definition layer
Runtime values: Out of scope
SSSR registry ownership: Unchanged
Primary objective: Separate governed information need from interaction item and from canonical signal identity.
1. Fundamental correction
The FOGE architecture should not be:
Pergamum Requirement
↓
FOGE Item
↓
signal_ref
It should be:
┌──────────────────────┐
│ Pergamum Requirement│
└──────────┬───────────┘
│
│ requires / constrains
▼
┌──────────────────────┐
│ FOGE Data Need │
│ semantic information│
└───────┬──────┬───────┘
│ │
interaction │ │ semantic resolution
mapping │ │
▼ ▼
┌──────────┐ ┌─────────────────┐
│FOGE Item │ │ SSSR Binding │
│ │ │ Group / Binding │
└──────────┘ └────────┬────────┘
│
▼
┌───────────────┐
│ SSSR Signal(s)│
└───────────────┘
The three identities remain distinct:
Requirement identity
≠
Data Need identity
≠
Interaction Item identity
≠
SSSR Signal identity
This is the core of the model.
2. Why Data Need must become a first-class object
A FOGE item is an interaction object.
A Data Need is a semantic information object.
They are not the same thing.
For example, a requirement may need:
worker gender category
worker business-unit relationship
workforce inclusion status
business-unit identity
FOGE may satisfy all four without rendering anything.
Or FOGE may render one confirmation item covering several of them.
Therefore:
A Data Need MUST exist independently of whether a user-facing FOGE Item exists.
Otherwise the architecture cannot naturally support zero-question results.
3. Data Need must also exist independently of a specific Requirement
The same governed information may satisfy several requirements.
Example:
PP Requirement A ─────┐
│
PP Requirement B ─────┼────► FOGE Data Need: employee count
│
PP Requirement C ─────┘
│
▼
SSSR Signal(s)
The requirements may impose different:
- applicability;
- freshness;
- evidence;
- attestation;
- derivation permissions;
- completeness; or
- estimation restrictions.
Those differences MUST NOT force us to create three semantically duplicate Data Needs.
Therefore:
Data Need defines what the information is.
Requirement ↔ Data Need binding defines what a particular requirement demands of that information.
This separation is critical.
4. Revised FOGE definition model
The design-time relational projection should contain seven principal objects.
core_metadata
│
├── foge_framework_releases
├── foge_forms
├── foge_form_versions
├── foge_sections
│
├── foge_items
├── foge_item_versions
│
├── foge_data_needs NEW
└── foge_data_need_versions NEW
core_relations
│
├── foge_form_item_memberships
│
├── foge_form_data_need_memberships NEW
├── foge_item_data_need_bindings NEW
├── foge_pergamum_data_need_bindings NEW
├── foge_data_need_sssr_binding_groups NEW
└── foge_data_need_sssr_bindings NEW projection
The existing direct:
foge_pergamum_requirement_bindings
requirement → item
should no longer be the canonical semantic relationship.
The canonical route becomes:
Pergamum Requirement
↓
FOGE Data Need
↓
FOGE Item where interaction is required
Requirement → Item lineage can always be derived through the Data Need.
5. core_metadata.foge_data_needs
This table provides the stable FOGE identity of a reusable semantic information need.
Conceptually:
data_need_id TEXT PK
canonical_name TEXT
description TEXT
status active | deprecated | retired
created_at
updated_at
Example conceptually:
data_need_id:
<governed FOGE data-need identifier>
canonical_name:
Worker gender classification
No permanent ID grammar should be invented until FOGE identity governance is resolved.
6. core_metadata.foge_data_need_versions
A Data Need's semantics are versioned and immutable after publication.
Conceptual shape:
data_need_version_id
data_need_id
version
publication_status
supersedes_data_need_version_id
semantic_concept_ref
semantic_description
value_kind
value_schema
grain
dimensions
unit_requirement
classification_vocabulary_ref
binding_selection_policy
source_path
content_digest
published_at
created_by
created_at
6.1 What belongs here
A Data Need version defines the information itself.
For example:
semantic_description:
Classification of a workforce member by the governed
gender-category vocabulary.
value_kind: classification
grain:
subject: workforce_member
cardinality:
intrinsic: one_per_subject
classification_vocabulary_ref:
<governed-reference>
Or:
semantic_description:
Relationship identifying the business unit to which
the workforce member belongs for the applicable period.
value_kind: relationship
grain:
subject: workforce_member
object: business_unit
6.2 What does NOT belong here
The Data Need itself should NOT say:
mandatory under Directive X
must be confirmed annually
estimates forbidden by Framework Y
evidence must be signed by supplier
applies above €450m turnover
Those are Requirement-specific constraints.
They belong on:
Pergamum Requirement ↔ Data Need
not on the reusable semantic Data Need.
7. core_relations.foge_pergamum_data_need_bindings
This becomes the principal bridge from Pergamum requirement semantics into FOGE.
Conceptually:
binding_id
data_need_version_id
pp_object_id
pp_object_version
binding_role
obligation_context
applicability_contract
temporal_scope
subject_scope
object_scope
cardinality
completeness
satisfaction_contract
evidence_expectation
attestation_policy
derivation_policy
estimation_policy
reuse_policy
acceptance_constraints
alternative_pathway_ref
binding_context
created_at
Exact complex structures should remain JSONB projections of the immutable compiled contract rather than be prematurely exploded into dozens of relational columns.
8. Requirement binding roles
One Data Need may have several Pergamum objects governing different aspects.
For example:
PP requirement assertion
→ requires
PP applicability assertion
→ applicability_basis
PP threshold assertion
→ applicability_constraint
PP evidence assertion
→ evidence_requirement
PP methodological assertion
→ methodology_constraint
PP permission assertion
→ derivation_permission
Recommended v0.1 semantic roles are:
requires
defines
applicability_basis
applicability_constraint
temporal_constraint
evidence_requirement
attestation_requirement
methodology_constraint
derivation_permission
estimation_permission
alternative_pathway
supersession_basis
These names should eventually be registry-governed rather than permanently embedded as an accidental SQL vocabulary.
9. This is where most of the Pergamum readiness issues land
For example:
applicability_contract:
<compiled Pergamum applicability semantics>
temporal_scope:
<compiled effective/reporting semantics>
completeness:
mode: complete_population
derivation_policy:
permitted: true
estimation_policy:
permitted: false
attestation_policy:
required: true
The authoritative basis remains the exact Pergamum object/version.
FOGE is storing the compiled execution contract, not independently recreating the law.
10. core_relations.foge_form_data_need_memberships
This is an especially important addition.
A Form Version must explicitly contain its complete Data Need set independently of its rendered items.
Conceptually:
membership_id
form_version_id
data_need_version_id
membership_configuration
created_at
Unique:
(form_version_id, data_need_version_id)
The complete design-time FOGE definition therefore becomes:
FOGE Form Version
│
├── complete Data Need set
│
└── interaction Item set
not:
FOGE Form Version
└── Items which happen to imply data requirements
This directly supports:
Complete requirement set before minimal projection.
11. Why Form ↔ Data Need is necessary
Suppose a form has eighty-seven governed Data Needs.
At runtime:
87 Data Needs
│
├── 76 resolved automatically
├── 5 not applicable
├── 3 require confirmation
└── 3 unresolved
Only six visible interactions may be required.
If Data Needs existed only through Items, the canonical definition would become dependent on what is rendered.
That would invert the architecture.
Therefore:
Form
↓
Data Need
is canonical.
Form
↓
Item
is interaction structure.
Both coexist.
12. core_relations.foge_item_data_need_bindings
An Item may interact with one or many Data Needs.
A Data Need may be represented by several different Items in different forms or contexts.
Therefore this relationship is many-to-many.
Conceptually:
binding_id
item_version_id
data_need_version_id
interaction_role
binding_context
created_at
Possible interaction roles include:
collects
confirms
attests
evidences
displays
selects
establishes_context
Example:
Item:
"Please confirm the workforce information below."
↓ confirms
Data Need A:
workforce population
Data Need B:
worker gender classification
Data Need C:
worker business-unit relationship
One interaction may therefore cover several Data Needs.
13. Interaction binding does not make the Item authoritative
The Item may change wording from:
Please provide...
to:
Please confirm...
without changing:
Data Need identity
Pergamum Requirement identity
SSSR Signal identity
That is exactly the flexibility FOGE needs.
14. Existing generic SSSR binding architecture
FOGE should NOT create its own signal registry or its own physical-addressing model.
The existing generic SSSR bridge already provides:
semantic source
↓
governed mapping reference
↓
SSSR binding
↓
SSSR signal
↓
physical binding / resolution semantics
A FOGE Data Need becomes a valid semantic source for that generic bridge.
Conceptually:
semantic_source:
source_system_id: <registered FOGE source-system identity>
source_namespace: <governed namespace>
object_type: data_need
object_id: <data_need_id>
object_version: <version>
property_path: value
The exact source_system_id and namespace must be registered rather than invented locally.
15. Semantic mapping still requires authority
A FOGE→SSSR binding does NOT itself prove semantic equivalence.
The existing SSSR bridge correctly requires a separate governed mapping reference.
Conceptually:
mapping_reference:
mapping_system: pergamum_pulse
mapping_id: PP-MAP-...
mapping_version: ...
where Pergamum provides the governing semantic crosswalk.
Thus:
FOGE says:
"I need concept X."
PP-SMCS / governed mapping says:
"Concept X is legitimately represented by SSSR Signal Y."
SSSR says:
"Signal Y is this canonical signal and can be addressed/resolved this way."
Those responsibilities remain distinct.
16. core_relations.foge_data_need_sssr_binding_groups
FOGE should persist a release projection of the generic SSSR Binding Group used for each Data Need.
Conceptually:
projection_id
data_need_version_id
semantic_property_path
sssr_binding_group_id
sssr_binding_group_version
path_key
path_priority
group_selection_policy
resolution_capability
group_status
group_snapshot_digest
provenance_digest
created_at
The SSSR Binding Group remains the governed external object.
FOGE stores a pinned projection/reference so the release is replayable.
17. Why Binding Groups matter
A Data Need can have more than one legitimate resolution strategy.
Example:
Data Need:
employee count
may have:
Path A
────────
authoritative HR signal
Path B
────────
payroll workforce signal
Path C
────────
composite derivation
active contracts
minus excluded worker classes
The paths may have priority and applicability conditions.
FOGE must not flatten this into:
signal_ref = something
18. Direct, alternative and composite paths
The existing generic SSSR Binding Group supports useful selection semantics.
FOGE can use those groups as resolution paths.
Direct
Data Need
↓
Binding Group
↓ single
Signal A
Alternative
Data Need
↓
Binding Group
↓ highest_priority_applicable
Signal A
Signal B
Signal C
Composite
Data Need
↓
Binding Group
↓ all_applicable
Signal A
Signal B
Signal C
Complex alternatives
For cases such as:
either:
Path A = Signal X
OR
Path B = Signal Y + Signal Z
FOGE can retain multiple binding groups as separate paths and select the applicable path through the Data Need's governed binding-selection policy.
19. core_relations.foge_data_need_sssr_bindings
This table is a projection, not another SSSR registry.
Its purpose is efficient FOGE lookup and immutable release replay.
Conceptually:
projection_binding_id
data_need_version_id
sssr_binding_group_id
sssr_binding_group_version
sssr_binding_id
sssr_binding_version
sssr_signal_id
binding_kind
priority
mapping_system
mapping_id
mapping_version
resolution_capability
binding_status
binding_snapshot_digest
provenance_digest
created_at
It MUST NOT contain:
tenant row ID
tenant-specific value
actual employee count
runtime evidence
runtime trust decision
Nor should it duplicate physical SSSR data such as:
database
schema
table
column
unless a deliberately generated release snapshot needs that information for historical replay.
The authoritative physical mapping remains SSSR-owned.
20. Many-to-many semantics
This produces the required relationship:
FOGE Data Need A ──┬── SSSR Signal 1
├── SSSR Signal 2
└── SSSR Signal 3
FOGE Data Need B ───── SSSR Signal 2
FOGE Data Need C ──┬── SSSR Signal 3
└── SSSR Signal 4
Therefore:
Data Need ↔ Signal
is many-to-many.
And importantly:
Requirement ↔ Data Need
is also many-to-many.
And:
Item ↔ Data Need
is also many-to-many.
The resulting FOGE semantic graph is:
Pergamum Requirements
M
│
│
N
FOGE Data Needs
M M
│ │
│ │
N N
FOGE Items SSSR Signals
21. Resolution capability
The FOGE projection should preserve the SSSR discovery result:
STORED
DERIVABLE
ACQUIRABLE
UNRESOLVED
as a snapshot of SSSR's governed resolution capability.
This must remain distinct from runtime Item state.
Example:
SSSR capability:
STORED
Runtime:
no applicable record
FOGE state:
MISSING
Or:
SSSR capability:
DERIVABLE
ZSSR materialization:
successful
Trust / validation:
acceptable
FOGE state:
SATISFIED
22. UNRESOLVED is not a signal binding
An important subtlety:
UNRESOLVED
means there is currently no approved path capable of satisfying the Data Need.
Therefore it should not create a fake sssr_signal_id.
A draft Data Need may exist with no approved signal binding.
A production FOGE release SHOULD normally be blocked if a mandatory applicable Data Need has no acceptable resolution/acquisition route.
That prevents FOGE from inventing a field simply to make compilation succeed.
23. Human entry remains an SSSR-governed acquisition route
Manual input should not bypass signal governance.
If a Data Need genuinely must be supplied by a user, the architecture should still be:
FOGE Data Need
↓
canonical SSSR Signal
↓
ACQUIRABLE
↓
user-contribution acquisition route
↓
FOGE Item
not:
FOGE Item
↓
random unregistered value
This ensures newly collected data becomes reusable canonical ZAYAZ data rather than a one-off questionnaire answer.
24. Revised responsibility of foge_item_versions
With Data Needs first-class, foge_item_versions should become much smaller.
The current model places:
signal_ref
value_schema
evidence_expectation
validation_rules
prefill_policy
directly on the Item.
That mixes semantic need, requirement policy and interaction presentation.
The revised Item should primarily hold:
item_version_id
item_id
version
publication_status
supersedes_item_version_id
item_type
prompt
help_text
interaction_configuration
presentation
ai_modification_policy
source_path
content_digest
published_at
created_by
created_at
25. Fields that move away from Item
signal_ref
Remove from Item.
Replaced by:
Item
↓
Data Need
↓
SSSR Binding Group
↓
SSSR Signal(s)
value_schema
Move to Data Need version.
The value structure describes the information, not the visual widget.
evidence_expectation
Move primarily to:
Pergamum Requirement ↔ Data Need binding
because two requirements may demand different evidence for the same value.
prefill_policy
Move primarily to Requirement ↔ Data Need execution semantics / runtime resolution policy.
One framework may permit reuse while another requires fresh attestation.
validation_rules
Separate:
semantic / acceptance validation
→ Requirement ↔ Data Need
signal structural validation
→ SSSR / DaVE
interaction-input UX validation
→ FOGE Item / FFG
This prevents FOGE from becoming another validation authority.
26. Revised foge_form_item_memberships
The current fields:
is_required
required_when
display_when
also need stricter boundaries.
is_required and required_when must NOT become a second legal-applicability model.
Mandatory semantics come from:
Pergamum
↓
Requirement ↔ Data Need
FOGE Item membership should contain only interaction semantics.
A safer future model is:
interaction_when
display_when
interaction_configuration
where those rules may determine:
show confirmation
show evidence uploader
hide satisfied item
group related unresolved needs
but may not declare a Pergamum-derived requirement non-applicable.
27. Complete form definition after the change
The design-time model becomes:
FOGE Framework Release
│
▼
FOGE Form Version
│
├─────────────────────────────┐
│ │
▼ ▼
Complete Data Need Set Interaction Item Set
│ │
│ │
├──── Requirement bindings │
│ │
├──── SSSR binding groups │
│ │
└───────────────┬─────────────┘
│
▼
Item ↔ Data Need
interaction map
This is much closer to the true FOGE architecture.
28. Workforce acceptance specimen
Suppose Pergamum provides one requirement:
Provide workforce headcount distributed
by business unit and gender category.
FOGE could compile five Data Needs:
DN-1 workforce member population
DN-2 workforce inclusion status
DN-3 business-unit identity
DN-4 worker → business-unit relationship
DN-5 worker gender classification
The identifiers above are illustrative only.
28.1 Pergamum bindings
The requirement binds to all five Data Needs.
Its binding semantics might say:
complete population required
reporting-period scope
no estimation
governed aggregation permitted
specific evidence standard
These constraints belong to the Requirement ↔ Data Need relationships.
28.2 SSSR bindings
Conceptually:
DN-1
→ workforce-member canonical signal
DN-2
→ active-employment-status canonical signal
DN-3
→ business-unit identity canonical signal
DN-4
→ workforce-member/business-unit relationship signal
DN-5
→ gender-classification signal
Some may have multiple alternative bindings.
For example:
DN-5
├── HR gender-classification signal
└── payroll gender-classification signal
but only where a governed mapping establishes that the alternative is semantically valid.
28.3 Runtime
FOGE first creates the complete requirement/data-need instance.
Then:
SSSR resolves capability
↓
ZSSR obtains/materializes values
↓
DaVE / TrustGate / DICE evaluate
↓
FOGE determines state
If everything is satisfied:
0 questions
If only confirmation is required:
1 confirmation
If one component cannot be resolved:
Delta interaction = only that unresolved component
29. Effect on the current 017
Before 017_create_foge_definition_foundation.sql is executed, I recommend changing it in one coherent revision.
Keep
foge_framework_releases
foge_forms
foge_form_versions
foge_sections
foge_items
foge_item_versions
foge_form_item_memberships
Add
foge_data_needs
foge_data_need_versions
foge_form_data_need_memberships
foge_item_data_need_bindings
foge_pergamum_data_need_bindings
foge_data_need_sssr_binding_groups
foge_data_need_sssr_bindings
Remove / replace
Remove from foge_item_versions:
signal_ref
Move or redesign:
value_schema
evidence_expectation
validation_rules
prefill_policy
Replace:
foge_pergamum_requirement_bindings
with:
foge_pergamum_data_need_bindings
as the canonical semantic binding.
Requirement→Item relationships may later be exposed through a view.
30. Why I would not keep signal_ref as a shortcut
It would be tempting to retain:
foge_item_versions.signal_ref
for convenience.
I recommend not doing so.
Even if documented as a convenience field, it introduces two competing representations:
Item.signal_ref
versus:
Item
↓
Data Need
↓
SSSR bindings
Eventually they will disagree.
For an end-state architecture, a derived view is safer:
v_foge_item_signal_bindings
The database can calculate that projection when developers need the simple representation.
The canonical data should remain normalized.
31. Relationship to the existing generic SSSR contracts
FOGE does not need another SSSR binding schema.
The existing contracts already provide:
sssr-binding.schema.json
sssr-binding-group.schema.json
sssr-binding-resolution.schema.json
sssr-bridge-profile.schema.json
FOGE should implement a registered FOGE profile of that generic bridge.
That future profile should state:
semantic source:
FOGE Data Need
target:
canonical SSSR Signal
mapping authority:
governed semantic mapping
runtime execution:
separate
tenant row identity:
never stored in design binding
This reuses the architecture already established for Pergamum and other semantic systems.
32. How this prepares the remaining Pergamum readiness work
The Data Need model does not magically resolve the earlier ⚠️ items.
It gives every resolution a correct architectural destination.
| PP readiness issue | Where its governed result lands |
|---|---|
| Effective / temporal semantics | Requirement ↔ Data Need temporal_scope |
| Requirement / prohibition / permission | exact Pergamum object/version + binding role |
| Mandatory / conditional / voluntary | Requirement ↔ Data Need obligation/satisfaction context |
| Applicability | Requirement ↔ Data Need applicability_contract |
| Thresholds | applicability/acceptance constraints |
| Exceptions | applicability/constraint contract |
| Subject/object scope | Requirement binding scope + Data Need grain |
| Alternative pathways | satisfaction contract + SSSR binding paths where data-related |
| Calculation permission | derivation_policy |
| Estimate permission | estimation_policy |
| Evidence expectations | evidence_expectation |
| Attestation | attestation_policy |
| Amendment/supersession | pinned PP objects + PP lineage + Data Need versioning |
| Cross-framework equivalence | governed mapping reference, e.g. PP-SMCS / PP-MAP |
| National transposition | must come from additional Pergamum sources; not a FOGE inference |
| Delegated/implementing acts | must be separately ingested/governed by Pergamum |
This gives us a concrete programme for closing every warning.
33. Important distinction for the last two readiness issues
Two categories cannot be solved from Directive (EU) 2026/470 alone:
national transposition
and:
later delegated / implementing acts,
guidance or authoritative dependencies
Pergamum must ingest and relate those additional authoritative sources.
FOGE must never compensate for an incomplete Pergamum corpus by searching the web or interpreting the missing law itself.
That is a Pergamum corpus-completeness problem.
34. Architectural invariants
The model establishes these invariants:
Requirement is not Data Need.
Data Need is not Item.
Data Need is not Signal.
Signal is not physical storage.
A Form contains its complete Data Need set independently of its visible Items.
Requirement-specific constraints belong on Requirement ↔ Data Need, not on the reusable Data Need.
Interaction semantics belong on Item ↔ Data Need, not on Requirement authority.
Signal equivalence requires governed mapping evidence.
FOGE reuses the generic SSSR bridge rather than creating a parallel binding system.
Runtime row identity and runtime values never enter design-time signal bindings.
A published release pins exact versions and digests required for replay.
A missing signal blocks or routes governance; it does not cause FOGE to invent a field.
Zero interaction remains a first-class successful outcome.
35. Canonical graph
The resulting model is:
PERGAMUM PULSE
│
Requirement Versions
│
│ M:N
▼
FOGE DATA NEEDS
┌─────────┼─────────┐
│ │ │
│ │ │
▼ ▼ ▼
Form Scope Items SSSR Binding
M:N M:N Groups
│
│ 1:N
▼
SSSR Bindings
│
│ N:1
▼
SSSR Signals
│
▼
SSSR Physical Bindings
│
▼
ZSSR
│
▼
Runtime Values
The semantic path remains:
Pergamum
tells FOGE what information is governed and under what conditions.
FOGE Data Need
gives that information a reusable executable semantic identity.
SSSR
maps the need to canonical ZAYAZ signals.
ZSSR
resolves/materializes the applicable runtime data.
FOGE Item
exists only if human or machine interaction remains necessary.
36. Governing design rule
The model can be summarized in one rule:
FOGE must model what it needs to know before it models what it needs to ask.