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>
7.8 KiB
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
Project Overview
inter-hub is the reference implementation of the Interaction Hub Framework (IHF) — a governed, observable interaction substrate for hub-based AI-enabled software systems. It treats every UI element as a governed artifact, creating a full traceability chain from rendered widget → user interaction → structured feedback → requirement candidate → decision record → implementation change → observed outcome.
Current state: Phases 1–12 complete. IHF v0.2 specification fully implemented. GAAF scorecard at 3.68 (Strong). The full learning loop is closed: Widget → Annotation → RequirementCandidate → Requirement → DecisionRecord → DeploymentRecord → OutcomeSignal → OutcomeCorrelation / PatternPerformanceRecord / InstitutionalKnowledgeEntry → AdaptiveThresholdConfig → improved routing and triage.
For situational context, read SCOPE.md. For architecture depth, read specs/InteractionHubFrameworkSpecification_v0.1.md.
Stack
- IHP (Integrated Haskell Platform) v1.5 — full-stack Haskell web framework, server-rendered + optional realtime
- Haskell (GHC 9.10) — strongly typed, functional
- PostgreSQL — canonical datastore, managed via Nix (no manual DB setup)
- Nix / devenv — reproducible environment
- Tailwind CSS — see
specs/TailwindForInteractionHubs_v0.2.mdfor IHF-specific conventions
Development Setup
Requires Determinate Nix + direnv:
# One-time environment setup
curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh
nix profile install nixpkgs#ihp-new
nix profile add nixpkgs#direnv
# Bootstrap IHP project (Phase 1, Task T01)
ihp-new inter-hub
cd inter-hub
devenv up
After devenv up:
- App server:
http://localhost:8000 - IHP IDE + Schema Designer:
http://localhost:8001
Key Commands
devenv up # Start dev environment (app + postgres + file watchers)
migrate # Run pending migrations
test # Run tests (auto-creates temp Postgres DB)
make static/prod.js static/prod.css # Production asset bundle
deploy-to-nixos production # NixOS deploy
Schema editing: use the IHP IDE at localhost:8001 or edit Application/Schema.sql directly. Code generation via localhost:8001/Generators.
Architecture
Core Domain Model (Phase 1)
| Entity | Role |
|---|---|
Hub |
Bounded domain of responsibility (Dev Hub, Ops Hub, etc.) |
Widget |
Smallest semantically governable interaction unit with stable ID |
WidgetVersion |
Version history of widget definitions |
InteractionEvent |
Recorded user/agent interaction (viewed, clicked, submitted, etc.) — append-only (enforced by PostgreSQL trigger) |
Annotation |
Structured comment attached to a widget with category |
ViewContext |
Logical location in the UI |
CapabilityReference |
Link to hub capability |
Traceability Chain
Widget → InteractionEvent / Annotation
→ RequirementCandidate (Phase 2)
→ DecisionRecord (Phase 3)
→ ImplementationChange → DeploymentRecord → OutcomeSignal
IHP Conventions
- Controllers live in
Web/Controller/, views inWeb/View/, types inWeb/Types.hs - Schema changes go in
Application/Schema.sql, then generate with IHP IDE - Use
AutoRefreshfor operator dashboards (server push on DB change) — not DataSync or Server-Side Components in Phase 1 - See
docs/ihp-ihf-mapping.mdfor how IHP capabilities map to IHF requirements
Widget Envelope
Every rendered widget wraps its HSX in a widgetEnvelope helper (Task T08) that injects the stable widget-id and view-context attributes, enabling client-side event capture without coupling to implementation.
UI Conventions
All hub interfaces follow the Tailwind layer model in specs/TailwindForInteractionHubs_v0.2.md:
Semantic Role → Visual Primitive → Tailwind Token → Screen Composition
Key rules:
- Every interactive element belongs to a named semantic role (
action-primary,nav-item,data-cell, etc.) - Use spacing rhythm from the spec; do not invent ad-hoc spacing
- State cues (hover, active, disabled, error) follow the defined color roles
Required Environment Variables
| Variable | Purpose |
|---|---|
IHP_SESSION_SECRET |
Session encryption key |
DATABASE_URL |
Postgres connection string |
IHP_BASEURL |
External URL (e.g., https://example.com) |
IHP_ANTHROPIC_API_KEY |
Anthropic API key for Phase 5 agent-assisted distillation |
Active Workplan
IHF v0.2 is complete. All 12 phases and the GAAF Compliance Foundation are implemented. No active workplan.
Completed workplans: IHUB-WP-0001 (Phase 1), IHUB-WP-0002 (Phase 2), IHUB-WP-0003 (Phase 3), IHUB-WP-0004 (Phase 4), IHUB-WP-0005 (Phase 5), IHUB-WP-0006 (Phase 6), IHUB-WP-0007 (Phase 7), IHUB-WP-0008 (Phase 8), IHUB-WP-0009 (GAAF Compliance Foundation), IHUB-WP-0010 (Phase 9 — External API Surface and Consumer SDKs), IHUB-WP-0011 (Phase 10 — Hub Registry and Widget Marketplace), IHUB-WP-0012 (Phase 11 — Advanced AI Federation), IHUB-WP-0013 (Phase 12 — Platform Memory and Continuous Learning).
GAAF Architecture Rules (enforced from IHUB-WP-0009)
These rules apply to all code written after Phase 8 completion:
- Type discriminator columns (
widget_type,event_type,category,policy_scope) must reference a registry table or carry a CHECK constraint. No bare TEXT for new type discriminators. - New hub-owned types must be declared in the hub's
HubCapabilityManifestbefore use. Register via the Extensions admin UI. - Core tables (
widgets,interaction_events,annotations,hubs, and their Phase 1–4 dependents) must not have new columns added without a corresponding update to/contracts/core/. - Append-only invariant on
interaction_eventsandoutcome_signalsis permanent. Never propose a migration that removes or bypasses those triggers.
Key Reference Docs
| File | Purpose |
|---|---|
SCOPE.md |
Situational guide — in/out of scope, terminology, entry points |
ARCHITECTURE-LAYERS.md |
GAAF-2026 layer map, scorecard, and compliance status |
specs/InteractionHubFrameworkSpecification_v0.1.md |
Full IHF spec (Phases 0–8, risks, design principles) |
specs/InteractionHubFrameworkSpecification_v0.2.md |
IHF extension spec (Phases 9–12) with GAAF foundation notes |
specs/GoodSoftwareArchitectureFramework_2026.md |
GAAF-2026 standard — the architectural compliance framework |
specs/TailwindForInteractionHubs_v0.2.md |
Agent-optimized Tailwind coding guide |
contracts/README.md |
Contract catalog — all IHF contracts by layer |
docs/domain-hub-extension-guide.md |
How to register a new domain hub (dev, ops, fin, sec) |
docs/functional-modules.md |
Functional module maturity register |
docs/ihp-overview.md |
IHP v1.5 fundamentals and dev workflow |
docs/ihp-data-and-queries.md |
Schema design, auto-generated types, query builder, migrations |
docs/ihp-controllers-views-forms.md |
Controller patterns, HSX, forms, validation, auth |
docs/ihp-realtime.md |
AutoRefresh vs DataSync vs HTMX decision guide |
docs/ihp-ihf-mapping.md |
IHP capability → IHF requirement mapping with schema templates |
Related Repositories
hub-core— planned shared Haskell library for domain hub bootstrapping;HubCapabilityManifestin inter-hub provides the DB-side registration contract until hub-core is implementedthe-custodian— State Hub (decision records, workstreams) that IHF governance integrates with- Downstream consumers:
dev-hub,ops-hub,fin-hub,sec-hub— must register viaHubCapabilityManifestbefore creating hub-owned type discriminators