FOGE Governed Specimen — Workforce Gender Distribution

1. Purpose

This specimen demonstrates how the FOGE definition and binding model handles a realistic governed requirement without collapsing requirement semantics, semantic information needs, interaction Items, SSSR Signals, and physical data into one object.

The specimen is intentionally based on the workforce-gender example already used in the FOGE architecture and executable 017 conformance suite.

The semantic requirement is:

For the applicable reporting context, provide workforce headcount distributed by business unit and gender category for the complete reporting population.

The principal FOGE Data Need is:

Workforce gender distribution by business unit.

The specimen proves that FOGE can represent the requirement as one governed semantic Data Need, resolve it directly or derivationally through SSSR, render only confirmation where necessary, and legitimately compile a Form Version containing zero interaction Items.

2. Governance status of the specimen

This page is a governed reference specimen, not a claim that the placeholder Pergamum and SSSR identities shown below are production-admitted registry objects.

The executable conformance suite uses fixture identities such as:

PP-REQ-WGD
PP-REQ-WGD-ATTEST
PP-REQ-WGD-ALT

sssr-group:test.wgd.direct
sssr-bind:test.wgd.direct
sssr:test.workforce_gender_distribution

Those identities are suitable for deterministic testing because they are created inside the disposable conformance environment.

They MUST NOT be treated as production Pergamum or SSSR authorities merely because this specimen documents them.

A production compilation must replace fixture identities with exact governed registry identities and versions that have passed their respective publication/admission rules.

The semantic model demonstrated here is canonical; the fixture registry IDs are illustrative test bindings.

3. What the specimen is proving

The specimen tests six architectural claims.

Claim 1 — The required disclosure output is the Data Need

The FOGE Data Need is the required semantic result:

Workforce gender distribution by business unit

It is not automatically decomposed into separate FOGE Data Needs for:

worker identity;
workforce inclusion status;
worker-to-business-unit relationship;
worker gender classification; or
reporting-period boundary.

Those may be SSSR dependencies used to derive the required output signal.

They become separate FOGE Data Needs only if Pergamum independently requires those values as governed outputs.

Claim 2 — Pergamum remains the requirement authority

FOGE pins an exact Pergamum object version and requirement-specific rules.

FOGE does not infer legal completeness or derivation permission from the Data Need itself.

Claim 3 — SSSR may satisfy one Data Need through several signals

The required output may be directly stored or derived from several canonical dependencies.

Claim 4 — Interaction is optional

A Data Need exists independently of any Item.

Claim 5 — Zero questions is a valid compiled outcome

A Form Version may contain the governed Data Need and approved SSSR resolution path with no Item memberships.

Claim 6 — Runtime can still produce different projections

The same governed semantic need may result in no interaction, confirmation, acquisition, or manual collection depending on runtime resolution, evidence, freshness, authority, and completeness.

4. Canonical semantic requirement

Pergamum should express the requirement independently of storage or UI.

Conceptually:

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

  data_needs:
    - need_key: workforce_gender_distribution

      semantic_concept:
        pp_concept_ref: <governed-concept-reference>

      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

The governing semantics say what must be produced and under what rules.

They do not say which database field or API endpoint should be read.

5. Reusable FOGE Data Need

The stable identity used by the conformance specimen is:

DN-WGD-BU

with canonical name:

Workforce gender distribution by business unit

A representative Data Need Version is:

data_need_id: DN-WGD-BU
version: 1.0.0
publication_status: published
semantic_concept_ref: concept:workforce-gender-distribution-by-business-unit
semantic_description: >-
  Workforce headcount distributed by business unit and gender category.
value_kind: structured_collection
value_schema:
  measure:
    concept: headcount
    type: integer
grain:
  subject: business_unit
dimensions:
  - gender_category
intrinsic_cardinality:
  mode: complete_population

This reusable semantic version says what the information means.

It does not say:

which requirement is using it;
whether evidence is required;
whether derivation is legally permitted;
whether estimation is permitted;
which SSSR path is selected;
whether a user needs to see an Item; or
whether the runtime context currently has a valid value.

Those concerns belong to other layers.

6. Compiled Data Need Use

When a Form Version uses the published Data Need Version, FOGE creates a row in:

core_relations.foge_form_data_need_memberships

Conceptually:

form_data_need_membership:
  form_version_id: <exact-form-version>
  data_need_version_id: <DN-WGD-BU-version-uuid>
  resolution_selection_policy: single
  requirement_binding_required: true
  resolution_binding_required: true
  allow_unresolved_resolution: false

This row is the Data Need Use.

It is not a copy of the Data Need meaning. It is the replay-specific use of that meaning inside one exact Form Version.

7. Pergamum binding

The Form Data Need Use must be bound to exact Pergamum authority.

The conformance fixture uses:

PP-REQ-WGD / 1.0.0

A representative binding is:

pergamum_data_need_binding:
  pp_object_id: PP-REQ-WGD
  pp_object_version: 1.0.0
  binding_role: requires

  completeness:
    mode: complete_population

  derivation_policy:
    permitted: true
    method_class:
      - governed_population_aggregation

  estimation_policy:
    permitted: false

This demonstrates the semantic split:

Reusable Data Need Version
  "what the information means"

        +

Pergamum binding
  "what this requirement demands of that information"

A different requirement may reuse DN-WGD-BU while imposing a different evidence, attestation, freshness, derivation, or acceptance contract.

8. Resolution path A — Direct STORED output signal

The simplest path is that SSSR already has a governed canonical signal representing the required output at the required grain.

Conceptually:

Data Need Use
      ↓
SSSR Binding Group
      ↓
canonical workforce-gender-distribution signal
      ↓
STORED

The conformance fixture represents this as:

binding_group:
  sssr_binding_group_id: sssr-group:test.wgd.direct
  sssr_binding_group_version: 1.0.0
  group_selection_policy: single
  resolution_capability: STORED
  group_status: active

binding:
  sssr_binding_id: sssr-bind:test.wgd.direct
  sssr_binding_version: 1.0.0
  sssr_signal_id: sssr:test.workforce_gender_distribution
  binding_kind: value_source
  resolution_capability: STORED
  binding_status: active

This proves only that the signal capability is STORED.

It does not prove that a valid runtime value exists for a particular organization and reporting period.

Runtime must still evaluate:

value existence;
grain and scope;
completeness;
freshness;
evidence;
access;
provenance;
validation; and
trust/acceptance requirements.

9. Resolution path B — Composite DERIVABLE output signal

A more interesting path is that the required output is not stored directly but can be derived from governed dependencies.

The semantic model is:

Required FOGE Data Need
Workforce gender distribution by business unit
                  ↓
        canonical derived output signal
                  ↓
              DERIVABLE
                  ↓
       governed dependency graph
          ├── worker inclusion/status
          ├── worker → business unit
          └── worker gender classification
                  ↓
       governed population aggregation
                  ↓
workforce headcount grouped by business unit and gender

The conformance fixture pins three SSSR member bindings:

sssr:test.worker.status
sssr:test.worker.business_unit
sssr:test.worker.gender

inside one DERIVABLE binding group.

Representative projection:

binding_group:
  sssr_binding_group_id: sssr-group:test.wgd.composite
  sssr_binding_group_version: 1.0.0
  group_selection_policy: all_applicable
  resolution_capability: DERIVABLE
  group_status: active

bindings:
  - sssr_signal_id: sssr:test.worker.status
    binding_kind: computation_input
    resolution_capability: STORED

  - sssr_signal_id: sssr:test.worker.business_unit
    binding_kind: computation_input
    resolution_capability: STORED

  - sssr_signal_id: sssr:test.worker.gender
    binding_kind: computation_input
    resolution_capability: STORED

The key architectural point is:

The dependency signals are SSSR resolution mechanics for the required output; they are not automatically additional FOGE Data Needs.

This prevents FOGE from turning every internal computational dependency into a questionnaire field.

10. Why total workforce headcount is insufficient

A semantically related signal is not necessarily sufficient.

For example:

total workforce headcount

cannot satisfy:

workforce headcount by business unit and gender category

where business-unit and gender detail are mandatory.

The binding must preserve at least:

meaning;
value shape;
grain;
dimensions;
population;
cardinality;
temporal basis; and
aggregation semantics.

A company-total ratio or company-total headcount is therefore not a valid automatic substitute merely because it belongs to the same workforce semantic family.

11. Confirmation-only interaction

Some requirements may accept the resolved value but still require an attestation or confirmation by an authorized actor.

The conformance fixture represents this with a separate Pergamum object:

PP-REQ-WGD-ATTEST / 1.0.0

and an attestation policy such as:

attestation_policy:
  required: true
  actor_role: authorized_representative

FOGE can then use the reusable Item:

ITEM-CONFIRM-WGD

with an Item Version such as:

item_type: confirmation
prompt: Please confirm the workforce gender distribution shown above.
interaction_configuration:
  confirmation: true

The form-scoped Item membership may declare:

interaction_when:
  data_need_state: NEEDS_CONFIRMATION

and the Item-to-Data-Need relationship uses:

interaction_role = confirms

The resulting model is:

Data is already available and acceptable
            ↓
Pergamum still requires attestation
            ↓
FOGE state = NEEDS_CONFIRMATION
            ↓
one confirmation Item

FOGE does not ask the user to re-enter the entire dataset merely because interaction is required.

12. Zero-question Form Version

The strongest proof of the model is that FOGE can compile a valid Form Version containing the Data Need and its governed resolution path but no Item memberships.

The conformance suite explicitly publishes such a Form Version.

Definition-time shape:

Form Version
    ↓
Data Need Use: DN-WGD-BU
    ↓
Pergamum binding: required
    ↓
SSSR Binding Group: STORED
    ↓
SSSR binding: canonical workforce-gender-distribution signal

Items: 0

This is a valid compiled definition because interaction is not the semantic center of the model.

At runtime, if the resolved candidate satisfies all governing constraints:

SATISFIED
    ↓
no interaction rendered

The system therefore produces a complete result with zero questions.

13. Delta interaction when runtime resolution is incomplete

The same compiled semantic contract can yield different runtime projections.

Case A — fully satisfied

acceptable complete value exists
        ↓
SATISFIED
        ↓
0 questions

Case B — value acceptable, attestation outstanding

acceptable complete value exists
        +
attestation required
        ↓
NEEDS_CONFIRMATION
        ↓
1 confirmation Item

Case C — governed acquisition route exists

value not currently available
        +
SSSR capability = ACQUIRABLE
        ↓
ZSSR attempts governed acquisition
        ↓
user interaction only if still unresolved or policy requires it

Case D — derivation dependencies incomplete

required output = DERIVABLE
        ↓
one governed dependency unavailable
        ↓
output not yet derivable
        ↓
runtime identifies the smallest unresolved acquisition/confirmation requirement

Case E — no governed path exists

SSSR capability = UNRESOLVED
        ↓
publication allowed only if the Form Data Need Use explicitly permits unresolved resolution
        ↓
runtime cannot invent a signal or silently mark the requirement satisfied

The Delta interaction is therefore the consequence of runtime resolution, not a static list of fields stored in the definition model.

14. Alternative SSSR sources and Data Need reuse

The same published Data Need Version can be reused by a later Form Version.

For example, a later Form might have two governed resolution paths:

Data Need Use: DN-WGD-BU
        ↓
resolution_selection_policy = highest_priority_applicable
        ↓
Path A: canonical HR source
Path B: canonical payroll source

The Data Need meaning does not change merely because the available sources differ.

This is why source-selection policy belongs to the Form Data Need Use and SSSR binding projections rather than to the reusable Data Need Version.

15. Table-by-table specimen map

Table	Workforce-gender role
`core_metadata.foge_data_needs`	Stable identity `DN-WGD-BU`
`core_metadata.foge_data_need_versions`	Published semantic meaning of workforce gender distribution by business unit
`core_metadata.foge_framework_releases`	Governing compiled release envelope
`core_metadata.foge_forms`	Stable Form identity for the interaction family
`core_metadata.foge_form_versions`	Exact compiled replay boundary
`core_relations.foge_form_data_need_memberships`	Exact use of `DN-WGD-BU` in the Form Version
`core_relations.foge_pergamum_data_need_bindings`	Exact workforce-gender requirement semantics and policies
`core_relations.foge_data_need_sssr_binding_groups`	Direct, derived, alternative, or unresolved resolution path
`core_relations.foge_data_need_sssr_bindings`	Exact SSSR Signal/binding members in the selected path
`core_metadata.foge_items`	Stable confirmation/input/evidence interaction identity where required
`core_metadata.foge_item_versions`	Reusable prompt/interaction definition
`core_metadata.foge_sections`	Optional presentation grouping
`core_relations.foge_form_item_memberships`	Form-specific placement and interaction condition
`core_relations.foge_form_item_data_need_bindings`	Declares that an Item confirms, collects, evidences, or reviews the Data Need Use

16. Example join lineage

For a Form Version that contains a confirmation Item, the lineage is:

foge_form_versions
        ↓
foge_form_data_need_memberships
        ↓
foge_data_need_versions
        ↓
foge_data_needs

foge_form_data_need_memberships
        ├──► foge_pergamum_data_need_bindings
        │         ↓
        │      pp.object_version
        │
        └──► foge_data_need_sssr_binding_groups
                  ↓
             foge_data_need_sssr_bindings
                  ↓
             SSSR identities

foge_form_item_memberships
        ↓
foge_item_versions
        ↓
foge_items
        │
        └──► foge_form_item_data_need_bindings
                  ↓
             same Form Data Need Use

Every form-scoped relationship carries or enforces the same form_version_id boundary.

17. Replay behavior

Assume the workforce-gender Form Version is published with:

DN-WGD-BU version 1.0.0
PP-REQ-WGD version 1.0.0
SSSR group version 1.0.0
SSSR binding version 1.0.0

Later, the legal requirement, semantic definition, or signal mapping may change.

FOGE does not rewrite the published Form Version.

Instead:

new Pergamum object version
and/or
new Data Need Version
and/or
new SSSR Binding Group / Binding version
        ↓
new draft Form Version
        ↓
compile and validate
        ↓
publish new Form Version

Historical replay continues to point at the exact versions and digests originally compiled.

18. What would make this specimen invalid

The specimen would violate the FOGE architecture if it did any of the following:

placed worker.gender_code directly in the reusable Data Need definition as the canonical source;
treated PP-REQ-WGD as production authority without actual Pergamum admission;
treated sssr:test.* fixture identities as production SSSR records;
created one FOGE Data Need for every internal derivation dependency without Pergamum independently requiring those outputs;
attached one signal_ref directly to a question and bypassed the Data Need Use;
treated STORED as equivalent to runtime SATISFIED;
assumed one existing worker record proved complete-population coverage;
treated applicability UNKNOWN as NOT_APPLICABLE;
published a Form Version with a required Data Need but no Pergamum binding;
published a Form Version with required resolution but no SSSR path;
allowed an UNRESOLVED path to contain approved member bindings; or
mutated the published Form child graph after publication.

19. Production admission checklist

Before this reference specimen becomes a real production workforce-gender compilation, the following must be resolved through governed registries rather than by local convention.

Pergamum

exact admitted requirement object ID;
exact admitted requirement version;
authoritative source lineage;
applicability contract;
temporal scope;
complete-population semantics;
evidence/attestation requirements;
derivation permissions;
estimation permissions; and
acceptance constraints.

SSSR

canonical workforce-gender output signal identity;
approved Binding Group identity and version;
approved Binding identity and version;
semantic match class;
required grain and dimensions;
dependency graph where derivable;
governed handler/computation reference;
lifecycle status;
snapshot digest; and
provenance digest.

FOGE

stable Form identity;
exact Form Version;
release identity;
published reusable Data Need Version;
optional published confirmation/evidence/input Item Versions;
complete Form Data Need set;
exact Pergamum bindings;
exact SSSR binding projections; and
successful Form publication validation.

No placeholder identifier should silently become production canon.

20. Executable proof already present in the repository

The architecture described in this specimen is not only conceptual.

The FOGE 017 conformance suite exercises the workforce-gender Data Need through multiple cases, including:

direct STORED resolution;
reuse of the same published Data Need in a later Form;
alternative source paths;
composite DERIVABLE resolution;
confirmation-only interaction;
zero-question publication;
cross-Form FK rejection;
publication rejection for missing Pergamum bindings;
publication rejection for missing SSSR paths;
unresolved-path governance;
selection-policy coherence; and
published graph immutability.

The executable source is:

/sql/tests/017_foge_definition_foundation_validation.sql

The persistence model is:

/sql/017_create_foge_definition_foundation.sql

The general manual explanation is:

/computation-hub-tables/foge/foge-definition-and-binding-model.mdx

21. Result

The workforce-gender example demonstrates the intended FOGE architecture:

Pergamum requirement
        ↓
required disclosure output
        ↓
FOGE Data Need
        ↓
Form-scoped Data Need Use
        ├── exact Pergamum binding
        └── governed SSSR resolution path
                  ↓
          runtime resolution
          ├── direct stored value
          ├── governed derivation
          ├── governed acquisition
          └── unresolved
                  ↓
          validation / completeness / trust
                  ↓
        ┌─────────┼──────────────┐
        ▼         ▼              ▼
   SATISFIED  NEEDS_CONFIRMATION  MISSING / acquisition needed
        │         │              │
        ▼         ▼              ▼
   0 questions  1 confirm     minimal Delta interaction

The model therefore proves the foundational FOGE principle:

Model what ZAYAZ needs to know first. Ask only for what remains unresolved.

GitHub Repo Request for Change (RFC)

1. Purpose​

2. Governance status of the specimen​

3. What the specimen is proving​

Claim 1 — The required disclosure output is the Data Need​

Claim 2 — Pergamum remains the requirement authority​

Claim 3 — SSSR may satisfy one Data Need through several signals​

Claim 4 — Interaction is optional​

Claim 5 — Zero questions is a valid compiled outcome​

Claim 6 — Runtime can still produce different projections​

4. Canonical semantic requirement​

5. Reusable FOGE Data Need​

6. Compiled Data Need Use​

7. Pergamum binding​

8. Resolution path A — Direct STORED output signal​

9. Resolution path B — Composite DERIVABLE output signal​

10. Why total workforce headcount is insufficient​

11. Confirmation-only interaction​

12. Zero-question Form Version​

13. Delta interaction when runtime resolution is incomplete​

Case A — fully satisfied​

Case B — value acceptable, attestation outstanding​

Case C — governed acquisition route exists​

Case D — derivation dependencies incomplete​

Case E — no governed path exists​

14. Alternative SSSR sources and Data Need reuse​

15. Table-by-table specimen map​

16. Example join lineage​

17. Replay behavior​

18. What would make this specimen invalid​

19. Production admission checklist​

Pergamum​

SSSR​

FOGE​

20. Executable proof already present in the repository​

21. Result​

1. Purpose

2. Governance status of the specimen

3. What the specimen is proving

Claim 1 — The required disclosure output is the Data Need

Claim 2 — Pergamum remains the requirement authority

Claim 3 — SSSR may satisfy one Data Need through several signals

Claim 4 — Interaction is optional

Claim 5 — Zero questions is a valid compiled outcome

Claim 6 — Runtime can still produce different projections

4. Canonical semantic requirement

5. Reusable FOGE Data Need

6. Compiled Data Need Use

7. Pergamum binding

8. Resolution path A — Direct STORED output signal

9. Resolution path B — Composite DERIVABLE output signal

10. Why total workforce headcount is insufficient

11. Confirmation-only interaction

12. Zero-question Form Version

13. Delta interaction when runtime resolution is incomplete

Case A — fully satisfied

Case B — value acceptable, attestation outstanding

Case C — governed acquisition route exists

Case D — derivation dependencies incomplete

Case E — no governed path exists

14. Alternative SSSR sources and Data Need reuse

15. Table-by-table specimen map

16. Example join lineage

17. Replay behavior

18. What would make this specimen invalid

19. Production admission checklist

Pergamum

SSSR

FOGE

20. Executable proof already present in the repository

21. Result