Why start here?
Dobby improves the system from real evidence, but only in a controlled, explainable, approval-aware way.
Adaptation
The part that makes tomorrow better than today
Controlled adaptation and safe system learning.
Dobby improves the system from real evidence, but only in a controlled, explainable, approval-aware way.
jhf-dobby is the adaptive-learning module in the Helpifyr stack. It ingests learning-relevant runtime traces, persists governed run and proposal state, evaluates replay-backed candidates, checks approvals through Warp, and keeps the whole flow aligned with canonical Fabric contract truth.
It is not a generic autonomy engine and not a hidden policy system. Dobby exists to make stack optimization explainable, replayable, bounded, and fail-closed.
Status Available now README sync 29 Apr 2026
When do I need this?
Start here when you want to understand how a system gets better without optimizing itself into breakage.
What role it plays here
Controlled adaptation and safe system learning.
Most systems either learn without control or do not learn at all. Dobby makes optimization possible without turning into a black box.
What the module actually does
It evaluates replays, creates proposals, checks approvals, and keeps improvement explainable, bounded, and fail-closed.
At the core
accepts governed runtime traces through a stable learning API
computes deterministic run, candidate, and provenance hashes
evaluates replay candidates against threshold contracts
creates proposal records for possible adaptive changes
consumes Warp approval truth for proposal checks
enriches learning state with optional Shuttle evidence, including read-only handoff outcome signals, and Bobbin-marked provenance
exposes health, readiness, metrics, and contract-facing runtime views
degrades safely when Fabric truth, approvals, or persistence are unavailable
What role it plays in the stack
Dobby owns:
run, replay, proposal, and metric state inside its own persistence boundary adaptive-learning runtime orchestration replay verdict calculation and proposal lifecycle transitions runtime-facing health, readiness, metrics, and learning endpoints
Dobby consumes:
Fabric as canonical truth for capability class, contract families, schema/matrix alignment, and admission posture Warp as approval-lane truth Shuttle as optional read-only handoff evidence Bobbin as a marked provenance sink
Dobby explicitly does not own:
Fabric contract registry or admission truth approval policy truth ERP, procurement, CRM, or supplier master truth autonomous repo mutation or ungoverned writeback
What this looks like in practice
Most systems either learn without control or do not learn at all. Dobby makes optimization possible without turning into a black box.
A signal comes in.
The system assigns the right role and path.
Execution happens through controlled handoffs.
Result and evidence return together.
How it fits into the system
Dobby does not stand alone. It connects to neighboring modules so a single capability becomes dependable follow-through.
Important boundary
Dobby stays bounded to its role as Controlled adaptation and safe system learning. It does not replace other modules; it makes its part of the system traceable, connectable, and reviewable.
What comes next
Bobbin Persistent memory and provenance layer. Tenter Runtime evidence, readiness, and provable execution. Pattern Consistency and control layer against drift. Warp Runtime orchestration and controlled execution steering. Beam Safety, upgrade, and change-verification layer. All modules Back to overview
What keeps this page honest
This explanation stays anchored to the module’s current truth, including its real boundaries, responsibilities, and contracts.
Dobby is the adaptation layer where the system gets better from real evidence without losing control.
It evaluates replays, creates proposals, checks approvals, and keeps improvement explainable, bounded, and fail-closed.
Most systems either learn without control or do not learn at all. Dobby makes optimization possible without turning into a black box.
Active part of the system with clearly defined boundaries.
Source and repo truth
This page is rendered from the repo-owned projection truth and remains tied to the README, module boundaries, and status.
GitHub JaddaHelpifyr/jhf-dobbyDobby
Most systems either learn without control or do not learn at all. Dobby makes optimization possible without turning into a black box.