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>
IHF Contract Catalog
Framework: GAAF-2026 Last reviewed: 2026-03-31 Repository: inter-hub
This directory contains the versioned, machine-readable contracts for each GAAF-2026 layer. Contract files are the authoritative declaration of interface, invariants, compatibility rules, and validation requirements for every public surface in the framework.
The canonical implementation of each contract is the PostgreSQL schema and Haskell controllers. These files are the discoverable declaration — the human and agent-readable companion that makes intent explicit without requiring the source code to be read.
Core Contracts
| Contract | File | Version | Status |
|---|---|---|---|
| Widget Envelope | core/widget-envelope-v1.md | 1.0 | Active |
| Append-Only Events | core/append-only-events-v1.md | 1.0 | Active |
Core contracts are immutable after activation. New requirements produce a new version (v1.1, v2.0); the old version remains readable for audit.
Functional Contracts
| Contract | File | Version | Status |
|---|---|---|---|
| Interaction Reporting API | functional/interaction-reporting-v1.md | 1.0 | Active |
| Module Maturity Labels | functional/module-maturity-labels.md | 1.0 | Active |
Functional contracts are evolvable with minor-version notice. Breaking changes require a major version bump and a deprecation window.
Extensions Contracts
| Contract | File | Version | Status |
|---|---|---|---|
| Hub Capability Manifest | extensions/hub-capability-manifest-v1.md | 1.0 | Active |
Extensions contracts govern how domain hubs register their vocabulary and capabilities with the framework.
Contract Lifecycle
Draft → Active → Superseded
↓
(never deleted — old versions remain for audit)
A contract becomes Active when:
- Its corresponding schema and code are deployed
- It is referenced in
ARCHITECTURE-LAYERS.md
A contract is Superseded when a new version replaces it. The old file
remains with a superseded_by note at the top.
Adding a New Contract
- Create the file in the appropriate layer directory
- Follow the header format: name, version, date, status, layer
- Document: interface, invariants, compatibility rules, validation rules, failure mode
- Add an entry to this README table
- Reference it in
ARCHITECTURE-LAYERS.md