Skip to main content

Concepts

Use this area when you need to understand how Helpifyr thinks before you choose an API, runbook, or rollout action.

What this area explains​

  • the system model and control-plane boundaries
  • how capability admission, MCP access, and skills guidance fit together
  • how governed lifecycle, identity projection, and authority handoff stay explicit
  • how work type, closeout truth, and owner readback stay explicit
  • how operator shell context, runtime projection, and memory authorization stay bounded
  • how event sourcing, events, state, and projections relate
  • where replay, idempotency, and read-model boundaries matter
  • how dependency and event-modeling truth support operator decisions
  • where human review sits in the loop
  • how learning and optimization stay review-gated

Architecture / Flow​

  1. System Model
  2. Agent Capability Plane
  3. MCP and Skills
  4. JARVIS
  5. Identity, Session, and Projected Authority
  6. Work Operating Model
  7. Mission Control and Operator Context
  8. Runtime Projection and Readback
  9. Memory Boundaries
  10. Event Sourcing
  11. Event and State Flow
  12. Event Modeling
  13. Business Capabilities
  14. Human Interaction
  15. Learning and Optimization
  16. Platform Truth

Current detailed pages​

Verification​

This area is working as intended when a reader can:

  1. explain what Fabric owns versus what downstream products own
  2. explain why capability admission and read-only projection matter before agent or runtime execution
  3. explain why MCP is an access layer and skills are guidance, not a second source of truth
  4. explain why governed lifecycle and promotion posture should not be inferred from local repo lore
  5. explain how identity, session handoff, and projected authority differ from runtime ownership
  6. explain why projected done is not the same as owner-cleared closeout
  7. explain why Mission Control is an operator shell, not a replacement for owner truth
  8. explain why runtime projection and readback are not the same as runtime mutation ownership
  9. explain why memory claims, tenant isolation, and fail-closed reason codes matter before storing or replaying context
  10. explain why event sourcing and replay-safe thinking matter before implementation choices
  11. trace how truth moves from contracts and events into projections and operator decisions
  12. identify when a human review step is mandatory

Common failure modes​

Jumping into implementation without the system model​

Problem:

  • readers can find routes and products but still misread ownership and control-plane boundaries.

Better path:

  • start with the concept pages before choosing tooling or operations detail, especially when event-sourced or projection-heavy surfaces are involved

Treating concepts as detached theory​

Problem:

  • the pages are read once and not connected back to verification or runbooks.

Better path:

  • use concepts as the model that explains why later verification and handoff pages are structured the way they are, not just as general background reading

Treating MCP, skills, and capability admission as the same thing​

Problem:

  • readers see agent-facing surfaces and assume every visible tool, skill, or runtime hook is equally admitted or authoritative.

Better path:

  • read Agent Capability Plane and MCP and Skills before assuming what is merely visible, what is admitted, and what is only guidance

Treating event flow as enough without event sourcing or replay boundaries​

Problem:

  • readers understand that events exist but still miss append-only truth, replay behavior, and projection lag or idempotency constraints.

Better path:

  • read Event Sourcing together with Event and State Flow before choosing integration, automation, or recovery behavior

Treating identity projection as if it were the same as runtime auth ownership​

Problem:

  • readers see a published surface or session handoff mode and assume the downstream runtime may invent rights or admin posture locally.

Better path:

  • read Identity, Session, and Projected Authority before assuming who owns access truth, who materializes runtime auth, and when projected authority still fails closed

Treating projected completion as if it were already terminal closeout truth​

Problem:

  • readers see projected status, generated work state, or a local green-looking surface and assume the work item is already complete.

Better path:

  • read Work Operating Model before claiming completion, especially when closeout still depends on owner readback, human approval, or synchronized downstream evidence

Treating the operator shell as if it owned platform or domain truth​

Problem:

  • readers see Mission Control or another human-facing summary surface and assume the shell may redefine owner truth, final closeout, or runtime authorization.

Better path:

  • read Mission Control and Operator Context together with Platform Truth before treating an operator surface as anything more than a human-facing control-plane lane

Treating memory or runtime projection as if it were free-form local state​

Problem:

  • readers assume runtime readback, projected claims, or memory writes may safely infer missing tenant, scope, or correlation data.

Better path:

  • read Runtime Projection and Readback plus Memory Boundaries before trusting projected claims or writing memory from incomplete local context

Next paths​