Skip to main content

Learning and Optimization

Use this page when you need to explain how Helpifyr improves workflows or documentation without turning learning into an uncontrolled mutation path.

When to use this page​

  • You are reviewing whether a learning loop is safe.
  • You need to separate analysis, recommendation, and mutation.
  • You need a public-safe posture for replay or improvement workflows.

Prerequisites​

  • You understand the owner and validation model.
  • You know whether the learning target is docs, runtime operations, or workflow quality.

Architecture / Flow​

Step-by-step procedure​

1. Separate observation from mutation​

Learning may include:

  • usage analysis
  • replay of known scenarios
  • recurring failure classification
  • recommendation generation

That does not mean the learning component may directly change owner truth.

2. Keep owner repos explicit​

Examples:

  • docs improvements:
    • reviewed in jhf-docs or the source owner repo
  • runtime changes:
    • reviewed in the runtime owner lane
  • automation changes:
    • reviewed against the same control-plane and security rules as any other workflow

For the semantic platform this separation is stricter:

  • Bobbin may project and assemble context, but it does not become the business-truth owner
  • Dobby may recommend relevance, source, budget, ontology, or knowledge-pack changes, but it does not mutate truth, admission, or authority
  • Warp binds an agent to admitted knowledge and model profiles, but it does not create facts
  • Fabric remains the owner of ontology, authority, model admission, and fail-closed verdict grammar

3. Require evidence and replayability​

Useful learning signals should be tied to:

  • a verifiable failure mode
  • a reproducible flow or replay lane
  • a measurable verification result
  • one exact knowledge, context, or retrieval policy revision

For semantic knowledge work, useful recommendation classes include:

  • missing-fact or stale-source detection
  • context-budget tuning
  • source-priority or authority posture suggestions
  • model-profile or retrieval-policy candidates
  • extension-onboarding gaps that blocked a real operator or integration path

4. Re-verify after approved improvement​

No optimization should be called successful without showing the post-change result in the owner verification lane.

5. Keep model choice governed and replaceable​

Learning and optimization may recommend a different admitted model profile, but they must not hardcode a specific LLM name into the operating contract.

Public-safe rule:

  • users, customers, or operators may request a different admitted model profile
  • the platform may block a choice for residency, capability, or safety reasons
  • recommendation lanes may compare profiles, but only an owner-reviewed model binding may change runtime truth

Verification​

This page is being applied correctly when:

  1. analysis is separated from mutation
  2. the owner lane for changes is explicit
  3. replay or post-change verification exists

Common failure modes​

Letting a learning system write canonical docs truth directly​

Problem:

  • quality and provenance controls disappear.

Better path:

  • route changes through reviewable owner repos

Treating recommendation quality as permission to change knowledge truth​

Problem:

  • a system that predicts relevance well starts behaving like an authority writer.

Better path:

  • keep Dobby proposal-only and require owner review plus replay evidence for every promoted change

Calling a recommendation an improvement without replay evidence​

Problem:

  • “optimization” becomes guesswork.

Better path:

  • require replay or before/after verification

Hardcoding one model name into a learning or retrieval lane​

Problem:

  • customer choice, residency posture, or provider retirement breaks the workflow even when equivalent admitted profiles exist.

Better path:

  • document and compare admitted model profiles, not one permanent hardcoded LLM identity

Source Truth​

Next paths​