Architecture / Importance Engine
The layer that decides which signals deserve weight.
Importance Engine sits above governed context and evidence feeds. It compares signals, weighs recurrence and contradiction, and returns either a low-latency score or a richer forensic explanation for human decision support.
Core layers
How Importance Engine is structured
01
Signal intake
Receives governed context, product behaviour, support posture, commercial indicators, local session state, or evidence summaries through explicit boundaries.
02
Weighting and scoring
Uses result types, Success Points, negative signals, confidence, recurrence, and mode-specific scoring to identify what should be acted on first.
03
Decision support output
Returns scores, explanations, dossiers, or response-pressure guidance that can be reviewed, audited, and challenged by the user.
Operating flow
The request path through the product
Context
UCL facts provide business grounding
The engine can use governed context snapshots when enterprise facts need to inform scoring.
Evidence
Forensic mode keeps provenance visible
Evidence, contradiction, confidence, and negative-signal handling are exposed without publishing private scoring tables.
Action
The next move is weighted
The output helps choose whether to prioritise, reassure, challenge, escalate, or investigate further.
Governance
Boundaries the architecture must respect
Privacy
Local-first emotional boundary
Klopp-style conversation and weight handling is documented as local-first. Cloud analytics are aggregate-only and must not include prompts, responses, raw weights, or context facts.
Audit
Forensic explanation path
Forensic mode is positioned around provenance, factor explanations, confidence, and contradiction handling.
Control
No silent sensitive automation
The public architecture frames the engine as decision support, not as an unaccountable automated decision maker.
Integration points
Where it connects to the wider stack
UCL
Governed context
Pull facts from Scout or Fortress when business context is needed.
MCP/API
Agent-facing tools
Expose scoring and dossier paths to controlled investigation and assistant workflows.
Local LLM
Loopback enrichment
Where local model use is enabled, the design keeps sensitive runtime boundaries explicit.
Evidence boundary
What this page proves, and what it does not claim yet
Built
Local engine surfaces
The repo contains Rust crates for core scoring, Klopp, Forensic, MCP/API, diagnostics, and privacy documentation.
Deferred
Native and model proofs
Local model, native vector-store, and full benchmark proofs are not claimed as production-ready from this marketing page.