KB-314E

WF Procedure Index — GO/NO-GO for prototype v0.1 (2026-06-23)

6 min read Revision 1
workflow-manageprocedure-indexgo-no-godecisionv0.1owner-decision2026-06-23

WF Procedure Index — GO / NO-GO for prototype v0.1

Path: knowledge/dev/laws-new/workflow-manage/reports/wf-procedure-index-go-no-go-v0.1.md Status: DECISION PACKET · Non-authorizing · read-only survey complete · 0 PG writes Date: 2026-06-23 Verdict code: WF_PROCEDURE_INDEX_V0_1_GO_CONDITIONAL_OWNER_APPROVES_3T2V


1. Recommendation: GO (conditional) for a thin prototype

Build the Option B-minus prototype: wf_procedure + wf_procedure_ingredient + wf_inventory_current (view) + wf_procedure_readiness (view); defer wf_procedure_link until M2M links are needed. Condition: Owner approves the DDL as a governed change (these are net-new tables → a Mức-3 / canonical create in this system's governance), and ref grammar v0.1 is frozen first.

This is a GO because every hard prerequisite is already satisfiable from existing, readable, authoritative PG sources — nothing in the critical path depends on governance/KG/birth being finished.


2. Why GO — evidence the feasibility bar is met

Acceptance criterion (macro §5) Status Evidence
Real source map of PG-readable inventory sources Survey §2: 9 SAFE kinds mapped to live sources w/ exact columns + counts (dot_tools 309, apr_action_types 14, event_type_registry 40, catalogs).
Clear ref grammar v0.1 ref-grammar-v0.1.md: 13 kinds, 2 normalization classes, per-kind probe + case + fallback.
Minimal design, not a large architecture 3 tables (start at 2) + 2 views; ≤ the problem statement's stated ceiling.
Performance model avoiding full-PG scans Per-procedure_code hot path; correlated EXISTS probes; pure views first, matview only if measured slow.
Readiness where PG/SQL is truth wf_procedure_readiness rollup; only SQL existence sets READY; pattern proven by 49 existing v_*readiness* views.
Ingredient Map = lazy cache, not truth Declared-only columns; computed status never stored; zero-ingredient procedures compute UNMAPPED not READY.
Decision on fuzzy/RAG/vector DEFER: only btree_gist/pgcrypto/plpgsql/postgres_fdw installed; native ILIKE for v0.1; pg_trgm/vector = owner-gated later, two-step only.
30–50 seed procedures 39 candidates across 10 domain groups.
GO/NO-GO recommendation This document.

None of the failure conditions (macro §5) are triggered: no engine proposed, no governance/KG/birth prerequisite, no PG mutation performed, manifest/RAG not treated as truth, no all-procedures/all-ingredients precondition, no all-object monster, refresh/perf addressed, ref grammar defined.


3. Conditions & owner decisions required before any build

  1. DDL authorization. wf_procedure + wf_procedure_ingredient (+ 2 views) are net-new objects → a governed/canonical create in this substrate (Đ32-class). Owner must approve via the governed path (patch_ops_code APR or a registered migration DOT). This survey does NOT authorize it.
  2. Freeze ref grammar v0.1 (companion doc) before writing the Inventory/Readiness views — the join key must be stable first.
  3. Confirm UNKNOWN_SOURCE kinds are acceptable for v0.1. io, checker, template, report have no clean PG SSOT today. Owner accepts they stay UNKNOWN_SOURCE (vs. blocking v0.1 to model them).
  4. template: source — pick iu_collection_template_registry vs design_templates vs none (NEEDS_OWNER_DECISION).
  5. pg_trgm — defer; if/when fuzzy ranking is wanted, approve CREATE EXTENSION pg_trgm as a separate small step.

4. Risks & unresolved unknowns

  • Overlap with workflows/workflow_steps (BPMN, 2 rows). Risk of two "process" stores. Mitigation: Procedure Index indexes workflows as procedure:WF-* (an object kind), does not duplicate or migrate it. Owner should confirm the two are intentionally distinct (system/operational procedures vs. human BPMN business processes).
  • function: overloading & label: facet ambiguity — v0.1 uses name-only / facet-flagged existence; precise signatures deferred to v0.2.
  • Assembly-layer sparsity — procedures are UNMAPPED for layer/domain; acceptable per problem statement (must not block), but treeview's assembly_layer × domain_group view will be mostly UNMAPPED until mapping happens.
  • reltuples unreliability — refresh/inventory must read real catalogs, not estimates (already baked into the design).
  • Registry-cache lag (trigger_registry, collection_registry) — prefer catalog over cache; mark registry_cache authority.
  • Naming collision with existing wf_* family — many wf_* tables exist (census/orphan/process-candidate). wf_procedure* names are free (verified absent) but Owner may prefer a distinct prefix (e.g. pidx_*) to avoid conceptual confusion with the wf_census/orphan scanner family.

5. Suggested next steps (after Owner GO)

  1. Freeze ref-grammar-v0.1.md.
  2. Owner-approve DDL for wf_procedure + wf_procedure_ingredient via governed path.
  3. Author wf_inventory_current (view, 9 SAFE branches) + wf_procedure_readiness (view).
  4. Seed the 39 candidates as rows; lazily declare ingredients starting with the one_button verification procedures.
  5. Measure; add wf_procedure_link and/or a materialized inventory cache only if needed.
  6. Nuxt treeview reads assembly_layer × domain_group from the views (read-only pane of glass).

6. Bottom line

GO for a 2-table + 2-view prototype, conditional on Owner approving the net-new DDL through the governed path and freezing ref grammar v0.1. The eye can be built on what PG already exposes; the hand (engine, governance, auto-fix) stays out of scope. Truth remains PG-computed; declarations remain hints.