Files

Bernd Worsch 0f505feb2d 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>

2026-04-03 12:34:07 +00:00

1.5 KiB

Raw Blame History

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

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:

{
  "signal_type": "success | adoption | satisfaction | ...",
  "value": 0.85,
  "observed_at": "2026-04-01T12:00:00Z"
}

The column starts NULL and is populated by:

The trg_enrich_lineage AFTER INSERT trigger on outcome_signals (automatic, real-time).
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)

1.5 KiB Raw Blame History