generated from coulomb/repo-seed
feat(WP-0013): IHF Phase 12 — Platform Memory and Continuous Learning
Closes the long-range feedback loop: outcome signals now enrich the full
traceability chain and feed back into routing, triage, and AI proposals.
Schema (T01):
- outcome_correlations (CHECK correlation_type)
- pattern_performance_records
- adaptive_threshold_configs
- institutional_knowledge_entries (GIN tsvector FTS)
- learning_insights (CHECK insight_type)
- ALTER TABLE decision_records + requirement_candidates: outcome_summary JSONB
- AFTER INSERT trigger trg_enrich_lineage on outcome_signals
- contracts/core/ updated (outcome-summary-columns-v1, append-only addendum)
Correlation engine (T02):
- Application/Helper/CorrelationEngine.hs: pure annotation→outcome SQL
- Web/Controller/OutcomeCorrelations.hs: ComputeCorrelationsAction + index
Pattern performance (T03):
- Web/Controller/PatternPerformance.hs: ComputePatternPerformanceAction
Adaptive thresholds (T04):
- Web/Controller/AdaptiveThresholds.hs: CalibrateThresholdsAction
- Application/Helper/FrictionScore.hs: applyAdaptiveWeights
Institutional knowledge (T05):
- DistilDecisionAction in DecisionRecords controller
- Web/Controller/InstitutionalKnowledge.hs: QueryKnowledgeBaseAction
Lineage enrichment (T06):
- Web/Controller/LineageEnrichment.hs: EnrichLineageAction (batch backfill)
- enrich_lineage_on_outcome_batch() PL/pgSQL helper in migration
Learning dashboard (T07):
- Web/Controller/LearningDashboard.hs: 5-panel autoRefresh view
- "Learning" nav link in FrontController
API v2 learning endpoints (T08):
- GET /api/v2/outcome-correlations, /pattern-performance, /knowledge-base/{id}
- OpenAPI schemas: OutcomeCorrelation, PatternPerformanceRecord, InstitutionalKnowledgeEntry
GAAF scorecard + docs (T09):
- Core 3.8→3.9, Functional 3.6→3.8, overall 3.61→3.68
- CLAUDE.md: IHF v0.2 complete, no active workplan
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -96,9 +96,26 @@ append semantics are enforced by application-layer controller conventions.
|
||||
|
||||
---
|
||||
|
||||
## Phase 12 Addendum — Lineage Enrichment Trigger
|
||||
|
||||
**Added in Phase 12 (IHUB-WP-0013 T06):** `outcome_signals` now has an
|
||||
`AFTER INSERT` trigger `trg_enrich_lineage` that calls
|
||||
`enrich_lineage_on_outcome()`.
|
||||
|
||||
This trigger:
|
||||
- Is **AFTER INSERT only** — it never fires on UPDATE or DELETE.
|
||||
- Does **not modify `outcome_signals`** — it only enriches upstream records
|
||||
(`decision_records.outcome_summary`, `requirement_candidates.outcome_summary`).
|
||||
- Is consistent with the append-only invariant: the `outcome_signals` row
|
||||
itself remains immutable after insertion.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Reference
|
||||
|
||||
- Functions: `prevent_interaction_event_mutation()`,
|
||||
`prevent_outcome_signal_mutation()` in `Application/Schema.sql`
|
||||
- Phase 12: `enrich_lineage_on_outcome()` — AFTER INSERT trigger on
|
||||
`outcome_signals`; enriches non-append-only columns on upstream tables only
|
||||
- The architectural fitness function `Test/Architecture/LayerBoundarySpec.hs`
|
||||
(Test 1) verifies these trigger names are present in the schema
|
||||
|
||||
66
contracts/core/outcome-summary-columns-v1.md
Normal file
66
contracts/core/outcome-summary-columns-v1.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# Outcome Summary Columns Contract
|
||||
|
||||
**Name:** outcome-summary-columns
|
||||
**Version:** 1.0
|
||||
**Date:** 2026-04-01
|
||||
**Status:** Active
|
||||
**Layer:** Core
|
||||
**Workplan:** IHUB-WP-0013 T01 / T06
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
Phase 12 adds `outcome_summary JSONB NULL` to two core tables —
|
||||
`decision_records` and `requirement_candidates` — to support retroactive
|
||||
lineage enrichment and learning queries without deep joins.
|
||||
|
||||
---
|
||||
|
||||
## Schema
|
||||
|
||||
```sql
|
||||
ALTER TABLE decision_records
|
||||
ADD COLUMN outcome_summary JSONB NULL;
|
||||
|
||||
ALTER TABLE requirement_candidates
|
||||
ADD COLUMN outcome_summary JSONB NULL;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Semantics
|
||||
|
||||
`outcome_summary` is a **JSONB array** of outcome signal snapshots. Each
|
||||
element has the shape:
|
||||
|
||||
```json
|
||||
{
|
||||
"signal_type": "success | adoption | satisfaction | ...",
|
||||
"value": 0.85,
|
||||
"observed_at": "2026-04-01T12:00:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
The column starts `NULL` and is populated by:
|
||||
|
||||
1. The `trg_enrich_lineage` AFTER INSERT trigger on `outcome_signals`
|
||||
(automatic, real-time).
|
||||
2. `EnrichLineageAction { hubId }` in `Web/Controller/LineageEnrichment.hs`
|
||||
(on-demand batch backfill).
|
||||
|
||||
---
|
||||
|
||||
## Mutation Rules
|
||||
|
||||
- Elements are **appended** via `COALESCE(outcome_summary, '[]'::jsonb) || new_element`.
|
||||
- No element is ever removed or modified.
|
||||
- Application code must never overwrite the column with a truncated array.
|
||||
|
||||
---
|
||||
|
||||
## Contract Dependencies
|
||||
|
||||
- `append-only-events-v1.md` — `outcome_signals` trigger clause
|
||||
- `decision_records` table (core, Phase 3)
|
||||
- `requirement_candidates` table (core, Phase 2)
|
||||
Reference in New Issue
Block a user