Jira progress: loading…

PP-TODO

Pergamum Pulse Rediness & To Do Plan

1. Readiness

FOGE need	Can PP derive it from the legal corpus?	Current 2026/470 run
Exact authoritative source	Yes	✅
Source version / capture / digest	Yes	✅
Article / paragraph / fragment evidence	Yes	✅
Jurisdiction	Yes	✅ structurally available
Effective/temporal semantics	Yes	⚠️ requires semantic interpretation
Requirement / prohibition / permission	Yes	⚠️ Knowledge Assertion stage needed
Mandatory / conditional / voluntary force	Yes	⚠️ Knowledge Assertion stage needed
Applicability	Yes	⚠️ must be interpreted and approved
Thresholds	Yes	⚠️ extraction → assertion needed
Exceptions	Yes	⚠️ semantic structure needed
Subject / object scope	Yes	⚠️ semantic structure needed
Alternative pathways	Yes	⚠️ semantic structure needed
Calculation/estimate permissions	Yes where law provides them	⚠️ semantic structure needed
Evidence/attestation expectations	Yes where legally specified	⚠️ semantic structure needed
Supersession / amendment relationships	Yes	⚠️ KORS/change processing needed
Cross-framework equivalence	Potentially	⚠️ PP-SMCS governance required
National-transposition effect	Yes, with the transposition corpus	⚠️ not derivable from this source alone
Later delegated acts / implementing acts	Yes, once separately ingested	⚠️ external dependency
Canonical ZAYAZ signal	No — SSSR	downstream
Physical data location	No — SSSR	downstream
Runtime materialization	No — ZSSR	downstream

---

2. Test cases - The semantic model passes all five scenarios

Case	Required architecture	Current 017	Result
1. Direct stored resolution	One Data Need → one stored SSSR signal	Supported	✅ Behaviour passes
2. Alternative SSSR sources	One Data Need → prioritized alternative bindings	Supported	✅ Behaviour passes
3. Composite derivation	Data Need → canonical derived signal → governed dependencies	Supported	✅ Passes, with SSSR owning computation
4. Confirmation-only	Existing value + confirmation Item	Supported	✅ Behaviour passes
5. Zero-question	Complete Data Need exists with no rendered Item	Supported explicitly	✅ Behaviour passes

The most important discovery is that the reusable Data Need should remain reusable across many Forms/releases. The current immutability triggers accidentally prevent that.

---

Case 1 — Direct stored resolution

Assume SSSR already contains:

sssr:<canonical workforce gender distribution signal>

and an acceptable value is stored.

FOGE definition:

Form Version
    ↓
Form Data Need Membership
    ↓
DN: workforce gender distribution by BU
    ↓
SSSR Binding Group
       selection = single
       capability = STORED
    ↓
SSSR Binding
       signal = canonical distribution signal
       kind = value_source

The DDL supports all of this.

foge_data_need_versions supports structured value shape, grain, dimensions and cardinality. foge_form_data_need_memberships independently puts that Data Need into the complete Form.

The SSSR projection then supports:

group_selection_policy = single
resolution_capability = STORED

and the member holds the canonical sssr: signal identity.

At runtime:

stored value
    ↓
acceptable evidence/trust
    ↓
SATISFIED
    ↓
0 questions

Behaviour result: ✅ PASS

But this exposed the first persistence problem, discussed below.

---

Case 2 — Alternative SSSR sources

Suppose the same Data Need can legitimately come from:

A. canonical HR-derived distribution
B. canonical payroll-derived distribution
C. approved supplier contribution

with governed priority:

HR       priority 10
Payroll  priority 20
Supplier priority 30

The current DDL can represent:

group_selection_policy =
    highest_priority_applicable

with multiple SSSR member bindings and independent priorities.

The allowed group policies already include:

single
first_applicable
highest_priority_applicable
all_applicable
manual_review
resolver

which align with the existing generic SSSR binding-group model.

Thus FOGE doesn't need:

if HR exists use HR else payroll...

inside its code.

The governed SSSR resolution path expresses it.

Behaviour result: ✅ PASS

This is exactly why replacing item.signal_ref was correct.

---

Case 3 — Composite derivation

This was the most interesting test.

Suppose no stored workforce-gender-distribution value exists.

But ZAYAZ has:

worker population
+
in-scope employment status
+
worker → business unit
+
gender classification

The correct architecture should not make FOGE the calculation engine.

Instead:

FOGE Data Need
workforce gender distribution
        ↓
SSSR canonical signal
workforce_gender_distribution_by_business_unit
        ↓
resolution capability = DERIVABLE
        ↓
SSSR dependency graph
        ├── worker status
        ├── worker business unit
        └── worker gender
        ↓
registered computation/handler
        ↓
derived canonical output

This matches the existing division of responsibility because FOGE only persists the SSSR signal/binding projection and DERIVABLE; it deliberately does not duplicate database location or calculation machinery.

Pergamum then controls whether this is legally acceptable through:

derivation_policy
estimation_policy
completeness
acceptance_constraints

and those fields already exist on foge_pergamum_data_need_bindings.

For example:

derivation_policy:
  permitted: true
  method_class:
    - governed_population_aggregation

estimation_policy:
  permitted: false

completeness:
  mode: complete_population

This cleanly prevents:

SSSR: "I can technically estimate this"

from overriding:

Pergamum: "estimation is not permitted"

Behaviour result: ✅ PASS

And this test reinforces an architectural rule:

FOGE binds to the required output. SSSR owns how that output is materially resolved or derived.

That is better than teaching FOGE the dependency graph.

---

Case 4 — Confirmation-only

Now assume ZAYAZ obtains a complete acceptable distribution automatically, but Pergamum says that an authorized representative must attest or confirm it.

The Data Need is already resolved.

Therefore FOGE should not ask:

Please enter workforce gender distribution:

It should produce:

We have calculated the following workforce distribution
from your governed HR data.

[distribution]

Please confirm this information.

The current model supports exactly this.

An Item Version can be purely an interaction object:

item_type = confirmation

with:

interaction_role = confirms

through foge_item_data_need_bindings. The Item itself no longer carries a signal_ref, value schema or evidence authority.

The Form membership can then conceptually use:

interaction_when:
  data_need_state: NEEDS_CONFIRMATION

while the authoritative attestation requirement remains:

Pergamum Requirement
        ↓
attestation_policy

not hidden inside interaction_when.

Behaviour result: ✅ PASS

This is a major improvement over the original 017.

---

Case 5 — Complete zero-question resolution

This is the key FOGE acceptance test.

Imagine all requirements applicable to the company resolve as:

Data Need 1 → SATISFIED
Data Need 2 → SATISFIED
Data Need 3 → NOT_APPLICABLE
Data Need 4 → SATISFIED
...

and none requires confirmation.

The Form still has its complete governed semantic definition because:

foge_form_data_need_memberships

exists independently of:

foge_form_item_memberships

There is no requirement in the DDL that a Data Need must have an Item.

Therefore:

Complete Form Instance
    ↓
all applicable Data Needs resolved
    ↓
projection finds no required interactions
    ↓
Delta Form
    =
EMPTY

Behaviour result: ✅ PASS

This is the strongest confirmation so far that introducing first-class Data Needs was the correct decision.

---

Final test result

I would score the current situation (2024.09.08):

Dimension	Result
Requirement ≠ Data Need	✅
Data Need ≠ Item	✅
Data Need ≠ Signal	✅
Many-to-many signals	✅
Direct stored resolution	✅
Alternative resolution	✅
Governed derivation	✅
Confirmation-only	✅
Zero-question	✅
Pergamum policy separation	✅
SSSR/ZSSR responsibility separation	✅
Reusable Data Need semantics	⚠️ trigger currently blocks correct reuse
Release-specific binding replay	❌ needs Form-Data-Need scope
Published Form dependency integrity	❌ needs publication validator
Item/Data-Need/Form consistency	❌ needs publication validator

The architecture itself passed the workforce specimen.

The test did exactly what we wanted it to do and found persistence constraints that would have hurt us later.

---