Skip to main content

Architect Escalation — PowerFill spec line 83 vs physical schema (F3)

STATUS: RESOLVED 2026-04-16. PO chose Option A: amend spec line 83 to make the sec-rule-rel guard authoritative; lockdown-derived guard remains a TBD follow-up pending PowerBuilder UI review. Spec powerfill-engine.md §Constraint Management and assumptions log A33 updated. This document preserved as the decision record.

Escalating to the Collaborator for Product Owner input / spec clarification.

The Question​

How should PSSaaS reconcile powerfill-engine.md line 83 (verbatim requirement below) with the current physical schema, which provides no join path from pfill_constraints to “active lockdown rules” in pfill_lockdown_guide?

Verbatim spec text (line 83):

Prevent deletion of constraints referenced by active lockdown rules

Schema facts (verified 2026-04-16):

  • pfill_constraints primary key: (investor_id, investor_instrument_name, constraint_name) — see 001_CreatePowerFillSchema.sql.
  • pfill_lockdown_guide primary key: pool_name only; columns include investor_instrument_name, trade_id, lock_pool, etc. — no constraint_name or investor_id, and no foreign key to pfill_constraints.
  • Therefore the spec sentence, read literally, is not implementable without a normative definition of “referenced by” (join chain or PB-derived rule).

Context​

  • PowerFill Phase 4 plan — Primary-Source Verification finding F3; Collaborator C1 required explicit traceability (no silent substitution of a weaker rule).
  • Phase 4 interim implementation ships a different enforceable guard: block DELETE on pfill_constraints while pfill_constraint_sec_rule_rel rows exist for that composite key. Assumptions log documents spec said X; code does Y; why until PO resolves.

Options Considered​

Option A: Amend spec (i) — sec-rule-rel as authoritative delete guard​

  • Summary: Update line 83 (and related acceptance criteria) so the documented rule matches what the schema can enforce today: cannot delete a constraint while securitization-rule associations exist; require deleting associations first.
  • Pros: Spec, schema, and code align; no guesswork join; Desktop coexistence preserved (ADR-006).
  • Cons: Spec text no longer mentions “lockdown” for deletes; if the Desktop App’s real behavior tied deletes to lockdowns, that nuance is deferred until PB review.

Option B: Spec-defined join chain (ii) — lockdown + sec-rule guards​

  • Summary: PO / Architect / legacy review defines the exact join or rule set that maps a constraint row to “active lockdowns” (e.g. lock_pool = 'y' plus instrument/pool semantics). Spec and tests encode that chain; code implements both sec-rule-rel check and lockdown linkage.
  • Pros: Spec line 83 can remain conceptually intact once the chain is written down.
  • Cons: Requires primary-source time in PowerBuilder (ue_delete_constraint, uo_tab_powerfill_constraints) and possibly Greg/Jay input; wrong chain ships a wrong guard.

My Recommendation​

Option A for near-term closure — amend spec line 83 to the enforceable sec-rule-rel rule, with a short note that “lockdown interaction on delete” remains TBD pending legacy UI review if we later discover a real linkage. Option B if Kevin confirms the business must match lockdown semantics before Phase 5.

Default Behavior If Unanswered​

Proceed with Option A as the documented spec amendment (Collaborator/PO can batch with other spec edits). Interim Phase 4 code and assumptions log remain as planned until the amended spec is merged.

Impact of Getting It Wrong​

  • If we pick B with a wrong join: users cannot delete constraints they should be able to delete (or vice versa) — operational pain and trust loss.
  • If we stay silent on A: “spec said lockdown; code did sec-rule” without PO-approved text — Gate Output / traceability failure (already guarded against in the Phase 4 plan).

Timeline​

Before Phase 5 carry-cost calculator work, the spec and assumptions log should reflect the chosen option so Phase 5+ developers do not re-litigate F3.