Skip to main content

FOGE Definition and Binding Model

1. Purpose​

This chapter explains how the canonical FOGE definition layer is persisted and how its tables work together.

It is written for engineers, architects, auditors, data designers, implementation partners, and AI engineering agents that need to understand the FOGE data model without reconstructing it from DDL or historical design discussions.

The central model is:

Pergamum requirement versions
        ↓
FOGE framework release
        ↓
FOGE form version
        ↓
complete form-scoped Data Need Uses
        ↓
Pergamum requirement bindings
        +
SSSR resolution binding groups and bindings
        ↓
optional form-scoped interaction Items

The most important invariant is:

Requirement identity, Data Need identity, interaction Item identity, SSSR Signal identity, and physical field identity are different identities and MUST remain different.

FOGE therefore models what information is required before it models what a user should be asked.

2. Architectural boundary​

The FOGE definition layer is a design- and governance-time persistence model.

It stores deterministic compiled definitions that can later be used by runtime systems. It does not store tenant values or runtime completion state.

2.1 Pergamum Pulse​

Pergamum Pulse owns authoritative requirement meaning, including:

  • requirement identity and version;
  • authoritative source lineage;
  • applicability semantics;
  • temporal scope;
  • subject and object scope;
  • cardinality and completeness;
  • evidence expectations;
  • attestation requirements;
  • derivation and estimation permissions;
  • reuse constraints;
  • acceptance constraints; and
  • alternative pathways.

FOGE pins the exact Pergamum object version used during compilation. FOGE does not reinterpret the governing legal or methodological source.

2.2 FOGE​

FOGE owns the compiled interaction contract:

  • release identity;
  • stable form identity and exact Form Version;
  • reusable semantic Data Needs;
  • the complete set of Data Need Uses for a Form Version;
  • reusable interaction Items;
  • form-scoped Item placement;
  • Item-to-Data-Need interaction relationships;
  • exact Pergamum requirement bindings;
  • exact SSSR resolution-path projections; and
  • publication and immutability rules.

2.3 SSSR​

SSSR owns canonical signal semantics and the governed mapping from semantic signals to physical data reality.

FOGE may pin:

  • SSSR binding-group identity and version;
  • SSSR binding identity and version;
  • SSSR Signal identity;
  • resolution capability;
  • governed mapping identity where applicable;
  • binding and provenance digests.

FOGE does not duplicate tenant row identity, runtime signal values, or SSSR-owned physical field mappings.

2.4 Runtime systems​

Runtime systems resolve whether the compiled Data Need is already satisfied and what interaction, if any, is still necessary.

Typical runtime responsibilities include:

  • ZSSR routing and materialization;
  • MICE or other governed computation;
  • DaVE validation;
  • DICE completeness and integrity;
  • TrustGate and assurance evaluation;
  • FFG rendering;
  • CRE-FFG contextual presentation; and
  • ZARA explanation and lineage.

The definition layer remains stable while runtime observations vary by tenant, subject, reporting period, source availability, evidence quality, and trust state.

3. Canonical object model​

The model has three different concepts that are easy to confuse: identity, version, and use.

Stable identity
    ↓
Reusable immutable version
    ↓
Use inside one exact Form Version

For example:

DN-WGD-BU
  stable Data Need identity
        ↓
Data Need Version 1.0.0
  reusable semantic definition
        ↓
Form Data Need Membership
  this exact Form Version's use of that semantic definition

The same pattern exists for interaction Items:

Stable Item identity
        ↓
Reusable Item Version
        ↓
Form Item Membership

This separation is what allows a semantic definition to be reused without allowing a later Form to mutate the meaning of an older published Form.

4. Schema placement​

FOGE definition persistence is split between two canonical schemas.

core_metadata​

Contains identities, versioned definitions, release metadata, and structural configuration.

core_relations​

Contains form-scoped relationships, memberships, requirement bindings, and SSSR binding projections.

The current definition model contains fourteen FOGE tables and one convenience view.

SchemaRelationRole
core_metadatafoge_framework_releasesGoverned release envelope for compiled FOGE definitions
core_metadatafoge_formsStable form identity
core_metadatafoge_form_versionsExact immutable compiled Form Version after publication
core_metadatafoge_sectionsStructural/presentation grouping inside one Form Version
core_metadatafoge_itemsStable interaction Item identity
core_metadatafoge_item_versionsReusable versioned interaction definition
core_metadatafoge_data_needsStable semantic Data Need identity
core_metadatafoge_data_need_versionsReusable versioned semantic definition
core_relationsfoge_form_data_need_membershipsComplete Data Need set for one Form Version; each row is a Data Need Use
core_relationsfoge_form_item_membershipsPlacement/use of an Item Version in one Form Version
core_relationsfoge_form_item_data_need_bindingsForm-scoped relationship between interaction Items and Data Need Uses
core_relationsfoge_pergamum_data_need_bindingsExact Pergamum requirement semantics applied to one Data Need Use
core_relationsfoge_data_need_sssr_binding_groupsForm-scoped governed SSSR resolution paths for one Data Need Use
core_relationsfoge_data_need_sssr_bindingsExact SSSR binding members pinned into a resolution path
core_relationsv_foge_item_signal_bindingsConvenience projection from Item → Data Need Use → SSSR Signal

5. Releases, forms, and Form Versions​

5.1 core_metadata.foge_framework_releases​

A framework release is the governed release envelope for one deterministic FOGE compilation set.

Important fields include:

FieldMeaning
release_idStable release identifier
framework_codeFramework or governed release family
release_versionVersion of the release
publication_statusdraft or published
source_pp_object_id / source_pp_object_versionOptional exact Pergamum source object pair for release-level lineage
supersedes_release_idPrior release replaced by this release
canonical_json_uriCanonical serialized release artifact
content_digestIntegrity digest of the published release
effective_from / effective_toEffective period where used

A published release is immutable.

A release can be published only after every child Form Version belonging to that release is already published.

5.2 core_metadata.foge_forms​

foge_forms stores stable Form identities.

A Form identity survives across versions. It represents the conceptual form or governed interaction family, not one immutable compiled snapshot.

Typical fields are:

  • form_id;
  • framework_code;
  • canonical_name;
  • description;
  • form_family; and
  • lifecycle status.

5.3 core_metadata.foge_form_versions​

A Form Version is the primary replay boundary.

It pins one exact compiled graph consisting of:

  • Data Need Uses;
  • Pergamum bindings;
  • SSSR resolution paths;
  • SSSR binding members;
  • Sections;
  • Item memberships; and
  • Item-to-Data-Need bindings.

Important fields include:

FieldMeaning
form_version_idUUID identity of this exact Form Version
form_idStable Form identity
release_idOwning framework release
versionForm semantic version
publication_statusdraft or published
supersedes_form_version_idPrior Form Version
content_digestDigest required for publication
form_configurationForm-level compiled configuration
effective_from / effective_toOptional effective period

A Form Version MUST be created as draft, compiled completely, validated, and then published.

Once published, both the Form Version and its compiled child graph become immutable.

6. Sections and presentation structure​

core_metadata.foge_sections provides structural grouping for interactions within a Form Version.

Sections are not the semantic source of truth. A Data Need can exist in a Form Version even when no Section or user-facing Item is required.

Key properties are:

  • section_id;
  • form_version_id;
  • section_key;
  • optional parent_section_id;
  • title;
  • sort_order; and
  • presentation.

The composite parent foreign key requires a parent Section to belong to the same Form Version.

Sections become immutable when their parent Form Version is published.

7. Data Needs: the semantic center of the model​

7.1 Stable identity: core_metadata.foge_data_needs​

A Data Need is a semantic information concept.

It answers:

What information does FOGE need to know?

It does not answer:

Which database field stores it?

and it does not answer:

Which question should a user see?

The stable identity table contains:

  • data_need_id;
  • canonical_name;
  • description; and
  • lifecycle status.

7.2 Reusable meaning: core_metadata.foge_data_need_versions​

A Data Need Version freezes the intrinsic meaning of the information object.

It may define:

FieldPurpose
semantic_concept_refGoverned semantic concept reference where available
semantic_descriptionHuman-readable canonical meaning
value_kindScalar, structured collection, classification, etc.
value_schemaExpected structural shape
grainSubject/object grain
dimensionsSemantic dimensions of the value
intrinsic_cardinalityCardinality intrinsic to the information object
unit_requirementIntrinsic unit semantics where material
classification_vocabulary_refGoverned classification vocabulary where required
content_digestIntegrity digest required when published

A published Data Need Version is immutable but reusable by future Forms.

Requirement-specific legal rules do not belong in the reusable Data Need Version. Those rules belong on the Pergamum-to-Data-Need binding for an exact Form Data Need Use.

8. Data Need Use: core_relations.foge_form_data_need_memberships​

This is one of the most important tables in the model.

A row in foge_form_data_need_memberships means:

This exact Form Version uses this exact published Data Need Version under this exact resolution policy.

The table therefore converts a reusable semantic definition into a compiled Data Need Use.

Key fields are:

FieldMeaning
membership_idIdentity of this Data Need Use
form_version_idExact Form Version
data_need_version_idReusable semantic definition being used
resolution_selection_policyPolicy for selecting between SSSR resolution paths
requirement_binding_requiredWhether publication requires Pergamum lineage
resolution_binding_requiredWhether publication requires an SSSR path
allow_unresolved_resolutionExplicit exception allowing only an UNRESOLVED path
membership_configurationForm-specific configuration for the use

The supported outer resolution-selection policies are:

single
first_applicable
highest_priority_applicable
all_applicable
manual_review
resolver

The default is intentionally strict:

  • Pergamum binding required;
  • SSSR resolution binding required; and
  • unresolved-only publication prohibited.

This is the form-scoped point where reusable semantic meaning becomes replay-specific configuration.

9. Pergamum requirement binding​

core_relations.foge_pergamum_data_need_bindings pins an exact Pergamum object version to an exact Data Need Use.

This table answers:

What does this particular governed requirement demand from this semantic Data Need in this Form Version?

The exact requirement identity is represented by:

pp_object_id
+
pp_object_version

and is enforced by a foreign key to pp.object_version(object_id, version).

Requirement-specific semantics are stored separately from the reusable Data Need definition, including:

  • 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; and
  • source_digest.

This separation is essential because two requirements may reuse the same Data Need while imposing different completeness, evidence, freshness, derivation, estimation, or acceptance rules.

10. SSSR resolution paths​

FOGE does not attach one signal_ref directly to an interaction Item.

Instead, a Data Need Use can have one or more governed resolution paths.

Data Need Use
      ↓
SSSR Binding Group projection
      ↓
one or more SSSR Binding projections
      ↓
canonical SSSR Signal identities

10.1 core_relations.foge_data_need_sssr_binding_groups​

Each row represents one form-scoped projection of an external governed SSSR Binding Group or resolution path.

Important fields include:

FieldMeaning
projection_idFOGE-local identity of the pinned path projection
form_version_idExact Form Version
form_data_need_membership_idExact Data Need Use
semantic_property_pathSemantic property within the Data Need; default value
sssr_binding_group_id / versionExternal governed SSSR group identity and version
path_keyLogical path key, such as primary
path_priorityOrdering between paths
group_selection_policyPolicy for choosing members inside this group
resolution_capabilitySTORED, DERIVABLE, ACQUIRABLE, or UNRESOLVED
group_statusGovernance lifecycle state
group_snapshot_digestDigest of the pinned external binding-group snapshot
provenance_digestDigest supporting binding provenance

10.2 Outer policy versus inner policy​

FOGE has two distinct selection levels.

Data Need Use
  resolution_selection_policy
        ↓
selects between SSSR groups / paths
        ↓
SSSR group
  group_selection_policy
        ↓
selects between member bindings inside that path

These policies MUST NOT be collapsed.

If the outer policy is single, the Data Need Use cannot publish with multiple SSSR groups.

If a group's inner policy is single, that group cannot publish with multiple member bindings.

10.3 Resolution capability is not runtime satisfaction​

The binding-group capability values are:

STORED
DERIVABLE
ACQUIRABLE
UNRESOLVED

These describe how a semantic signal can be obtained.

They do not describe whether a particular tenant or reporting period already has a valid value.

For example:

STORED

means ZAYAZ knows a governed stored representation exists. It does not mean the runtime Data Need is already satisfied.

11. SSSR binding members​

core_relations.foge_data_need_sssr_bindings pins exact SSSR binding members into one exact group projection.

Important fields are:

FieldMeaning
projection_binding_idFOGE-local projection identity
projection_idParent SSSR group projection
sssr_binding_id / versionExact external binding identity and version
sssr_signal_idCanonical SSSR Signal identity
binding_kindRole played by the binding, such as value source or computation input
priorityMember ordering
mapping_system / mapping_id / mapping_versionOptional governed mapping triplet
resolution_capabilityMember capability
binding_statusGovernance lifecycle state
binding_snapshot_digestDigest of the pinned binding snapshot
provenance_digestBinding provenance digest

The mapping triplet is all-or-nothing: the three mapping fields must either all be absent or all be present.

FOGE stores enough information to replay which governed binding was selected, but not SSSR-owned physical field semantics or runtime values.

12. Interaction Items​

12.1 Stable identity: core_metadata.foge_items​

An Item is an interaction concept.

Examples include:

  • confirmation;
  • manual input;
  • evidence upload;
  • attestation;
  • review; or
  • guided action.

An Item is not the semantic information itself.

12.2 Reusable version: core_metadata.foge_item_versions​

An Item Version may define:

  • item_type;
  • prompt;
  • help_text;
  • interaction_configuration;
  • presentation;
  • ai_modification_policy; and
  • integrity/source metadata.

Published Item Versions are immutable and reusable by later Forms.

12.3 Form-scoped use: core_relations.foge_form_item_memberships​

A Form Item Membership places one published Item Version inside one exact Form Version and Section.

It adds form-specific behavior such as:

  • sort_order;
  • interaction_when;
  • display_when; and
  • membership_configuration.

The Item remains optional at the model level. A complete Form Version can contain Data Need Uses and no Item memberships at all.

That is how FOGE supports a valid zero-question result.

13. Item-to-Data-Need relationship​

core_relations.foge_form_item_data_need_bindings links interaction to semantic need.

The relationship is many-to-many:

Item A ─────┐
            ├──► Data Need 1
Item B ─────┘

Item C ─────► Data Need 2
      └─────► Data Need 3

This supports:

  • one Item confirming several Data Needs;
  • several Items contributing to one Data Need;
  • different interaction projections for the same semantic Data Need; and
  • no Item at all when runtime resolution is sufficient.

The interaction_role explains the purpose of the relationship, for example:

collects
confirms
attests
evidences
reviews

Composite foreign keys enforce that both the Item membership and the Data Need membership belong to the same form_version_id.

This prevents cross-form semantic leakage.

14. Why the model is many-to-many​

The model intentionally permits:

Requirement ↔ Data Need​

Several Pergamum requirements may rely on the same semantic information.

One requirement may also require several Data Needs.

Data Need ↔ Item​

One Data Need may be collected, confirmed, evidenced, or reviewed through different Items.

One Item may cover several related Data Needs.

Data Need ↔ SSSR Signal​

One Data Need may map directly to one signal, use alternative signal paths, or be derivable from several input signals.

This is why the architecture cannot safely be reduced to:

requirement → question → signal_ref

15. Publication lifecycle​

Publication is the point where a compiled definition becomes replayable and immutable.

The intended sequence is:

1. Create stable Data Need identity
2. Create and publish reusable Data Need Version
3. Create stable Item identity where interaction is needed
4. Create and publish reusable Item Version
5. Create draft framework release
6. Create draft Form Version
7. Compile complete Data Need Uses
8. Pin exact Pergamum requirement bindings
9. Pin exact SSSR binding groups and member bindings
10. Add Sections and optional Item memberships
11. Bind Items to Data Need Uses
12. Publish Form Version
13. Publish framework release

15.1 Drafts remain editable​

Draft definition rows and draft compiled graphs may be changed while compilation is incomplete.

15.2 Published reusable definitions freeze meaning​

Published Data Need Versions and Item Versions cannot be updated or deleted.

A semantic change requires a new version.

15.3 Published Form Versions freeze the compiled graph​

After a Form Version is published, FOGE blocks later insertion, update, deletion, or movement of its form-scoped children.

This includes:

  • Sections;
  • Data Need Uses;
  • Item memberships;
  • Item-to-Data-Need bindings;
  • Pergamum bindings;
  • SSSR binding-group projections; and
  • SSSR binding projections.

15.4 Published releases freeze child membership​

After a framework release is published, later Form Versions cannot be inserted into, moved into, updated within, or deleted from that published release.

16. Form publication gates​

A Form Version cannot be published merely because all rows exist.

The publication validator enforces semantic readiness.

A Form Version is rejected where any of the following is true:

  1. a referenced Data Need Version is not published;
  2. a referenced Item Version is not published;
  3. a Data Need Use requires Pergamum lineage but has no Pergamum binding;
  4. a Data Need Use requires SSSR resolution but has no SSSR group;
  5. unresolved-only SSSR resolution is present without explicit allow_unresolved_resolution = true;
  6. a resolvable SSSR group has no member binding;
  7. an UNRESOLVED SSSR group contains member bindings;
  8. a resolvable SSSR group is not active or active_with_conditions;
  9. an SSSR member binding is not active or active_with_conditions;
  10. a Data Need Use uses outer policy single but has multiple SSSR groups; or
  11. an SSSR group uses inner policy single but has multiple member bindings.

An explicitly UNRESOLVED group is permitted only where the Data Need Use deliberately allows unresolved publication, and that unresolved group must contain no approved binding members.

17. Replay and historical correctness​

The Form Version is the historical replay boundary.

This is why FOGE pins exact versions and digests instead of following "latest" SSSR or Pergamum state at replay time.

A historical Form Version should answer:

  • which reusable Data Need Version was used;
  • which Pergamum object version governed it;
  • which SSSR binding group and binding versions were selected;
  • which SSSR Signal identities participated;
  • which Item Versions were available;
  • which interaction relationships were compiled; and
  • which release contained the Form Version.

Later governance changes create new versions or new Form Versions rather than rewriting history.

18. Runtime states are outside this layer​

The following runtime states are conceptually important to FOGE but are not stored in the definition tables described in this chapter:

SATISFIED
PREFILLED
NEEDS_CONFIRMATION
MISSING
NOT_APPLICABLE
WAIVED
BLOCKED

Those states belong to runtime resolution and projection.

The definition layer also does not store:

  • tenant signal values;
  • tenant row identities;
  • completed Form Instances;
  • runtime applicability decisions;
  • TrustGate decisions;
  • evidence-evaluation results;
  • current user responses;
  • Delta Form instances;
  • rendered UI state; or
  • SSSR-owned physical database field mappings.

A definition row describes what the compiled contract is.

A runtime row or observation describes what is true for this execution context now.

The distinction MUST remain explicit.

19. Common query patterns​

19.1 List the complete Data Need set for one Form Version​

SELECT
    fdnm.membership_id,
    dn.data_need_id,
    dn.canonical_name,
    dnv.version,
    dnv.semantic_description,
    fdnm.resolution_selection_policy
FROM core_relations.foge_form_data_need_memberships fdnm
JOIN core_metadata.foge_data_need_versions dnv
  ON dnv.data_need_version_id = fdnm.data_need_version_id
JOIN core_metadata.foge_data_needs dn
  ON dn.data_need_id = dnv.data_need_id
WHERE fdnm.form_version_id = :form_version_id
ORDER BY dn.data_need_id;

19.2 Trace Data Need Uses to Pergamum authority​

SELECT
    fdnm.membership_id,
    dnv.data_need_id,
    ppb.pp_object_id,
    ppb.pp_object_version,
    ppb.binding_role,
    ppb.completeness,
    ppb.derivation_policy,
    ppb.estimation_policy
FROM core_relations.foge_form_data_need_memberships fdnm
JOIN core_metadata.foge_data_need_versions dnv
  ON dnv.data_need_version_id = fdnm.data_need_version_id
JOIN core_relations.foge_pergamum_data_need_bindings ppb
  ON ppb.form_data_need_membership_id = fdnm.membership_id
 AND ppb.form_version_id = fdnm.form_version_id
WHERE fdnm.form_version_id = :form_version_id;

19.3 Trace Data Need Uses to SSSR resolution paths​

SELECT
    fdnm.membership_id,
    dnv.data_need_id,
    sgrp.path_key,
    sgrp.resolution_capability AS path_capability,
    sgrp.sssr_binding_group_id,
    sb.sssr_binding_id,
    sb.sssr_binding_version,
    sb.sssr_signal_id,
    sb.binding_kind,
    sb.resolution_capability AS binding_capability
FROM core_relations.foge_form_data_need_memberships fdnm
JOIN core_metadata.foge_data_need_versions dnv
  ON dnv.data_need_version_id = fdnm.data_need_version_id
JOIN core_relations.foge_data_need_sssr_binding_groups sgrp
  ON sgrp.form_data_need_membership_id = fdnm.membership_id
 AND sgrp.form_version_id = fdnm.form_version_id
LEFT JOIN core_relations.foge_data_need_sssr_bindings sb
  ON sb.projection_id = sgrp.projection_id
 AND sb.form_version_id = sgrp.form_version_id
WHERE fdnm.form_version_id = :form_version_id
ORDER BY sgrp.path_priority, sb.priority;

19.4 Inspect Item → Data Need → Signal relationships​

SELECT *
FROM core_relations.v_foge_item_signal_bindings
WHERE form_version_id = :form_version_id
ORDER BY item_version_id, data_need_version_id, binding_priority;

The convenience view is intentionally form-scoped. It must not be used to infer that an Item directly owns a signal.

19.5 Detect a definition-level zero-question Form​

SELECT
    fv.form_version_id,
    count(DISTINCT fdnm.membership_id) AS data_need_uses,
    count(DISTINCT fim.membership_id) AS interaction_items
FROM core_metadata.foge_form_versions fv
LEFT JOIN core_relations.foge_form_data_need_memberships fdnm
  ON fdnm.form_version_id = fv.form_version_id
LEFT JOIN core_relations.foge_form_item_memberships fim
  ON fim.form_version_id = fv.form_version_id
WHERE fv.form_version_id = :form_version_id
GROUP BY fv.form_version_id;

A Form Version may legitimately have Data Need Uses and zero interaction Items.

Runtime still determines whether the Data Needs are actually satisfied for a particular execution context.

20. Design invariants​

The definition model should be reviewed against the following invariants.

Invariant 1 — Meaning before interaction​

FOGE MUST model what it needs to know before it models what it needs to ask.

Invariant 2 — Requirement is not Data Need​

Pergamum requirement semantics are bound to a Data Need Use; they are not embedded into the reusable Data Need definition.

Invariant 3 — Data Need is not Item​

A semantic need may exist with no user-facing interaction.

Invariant 4 — Data Need is not SSSR Signal​

FOGE owns the semantic need within the interaction contract; SSSR owns canonical signal semantics and resolution metadata.

Invariant 5 — Signal is not physical field​

FOGE stores SSSR identities and governed binding snapshots, not physical field ownership.

Invariant 6 — Form Version is the compiled replay boundary​

All replay-specific bindings are scoped to the exact Form Version.

Invariant 7 — Published means immutable​

A published semantic version or compiled Form graph is replaced through new versioning, not in-place mutation.

Invariant 8 — Unknown is explicit​

Where governed resolution is incomplete, the model uses an explicit UNRESOLVED path rather than silently inventing a signal or treating missing information as non-applicable.

21. Implementation references​

The canonical persistence implementation is maintained in:

/sql/017_create_foge_definition_foundation.sql

The executable conformance suite is maintained in:

/sql/tests/017_foge_definition_foundation_validation.sql

The related architectural contracts are maintained in the same FOGE manual area:

/computation-hub-tables/foge/pp-to-foge-requirement-execution-contract.mdx
/computation-hub-tables/foge/foge-to-sssr-signal-discovery.mdx
/computation-hub-tables/foge/foge-many-to-many-signal-binding-model.mdx

The detailed FOGE engine behavior is maintained in:

/computation-hub-calcs/form-engine.mdx

The workforce-gender governed reference specimen provides the worked model for the relationships described in this chapter.

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