Skip to main content

JARVIS

Use this page when you need to understand how Helpifyr governs shared skill, handoff, trace, and learning families without turning that governance into a second execution system.

When to use this page​

  • You need to know why shared families such as skill lifecycle, trace envelopes, or learning signals do not drift into repo-local semantics.
  • You are checking whether a lifecycle, promotion, or learning surface is draft, active-limited, active, or blocked.
  • You need the public-safe explanation of governed skill lifecycle before reading product-specific learning or execution detail.

Prerequisites​

  • You have read Agent Capability Plane.
  • You want the governance layer that sits above individual skill packs or learning consumers.

Architecture / Flow​

Step-by-step procedure​

1. Treat JARVIS as governance truth, not as a second runtime​

JARVIS anchors one canonical lifecycle and family vocabulary for shared skill, handoff, trace, and learning work.

That means:

  • Fabric owns the governance truth
  • downstream repos consume it read-only
  • local execution or runtime behavior is still owned elsewhere

2. Keep lifecycle and promotion posture explicit​

JARVIS exists so repos do not invent local meanings for:

  • draft versus active-limited versus active posture
  • family admission and visibility
  • promotion-aware learning or skill lifecycle work
  • closure and resolver posture across repos

3. Use family truth before you infer a governed lane​

Shared families such as skill-lifecycle.v1, skill-promotion.v1, trace-envelope.v1, or learning-signal.v1 should be read from the canonical JARVIS surfaces first.

This keeps:

  • producer and consumer expectations aligned
  • learning posture reviewable
  • fail-closed behavior explicit when a family is still draft or blocked

4. Keep execution and adoption separate from governance visibility​

A family being visible in JARVIS does not mean every downstream runtime has already implemented or enforced it.

Public-safe reading should distinguish:

  • governance truth
  • downstream adoption evidence
  • runtime execution ownership

Verification​

This page is being applied correctly when a reader can:

  1. explain why JARVIS extends Fabric governance instead of becoming a second execution system
  2. distinguish family visibility from downstream implementation or enforcement
  3. explain why missing or conflicting governed posture must stay fail-closed

Common failure modes​

Treating JARVIS as a runtime product​

Problem:

  • readers assume JARVIS is the place where work executes rather than the place where family and lifecycle semantics are governed.

Better path:

  • treat JARVIS as governance truth, then follow the downstream owner repo for actual runtime behavior

Treating visible family registration as complete downstream adoption​

Problem:

  • a shared family is visible in registry truth and that visibility gets mistaken for finished runtime rollout.

Better path:

  • read governance truth together with downstream adoption or readiness posture before calling a lane complete

Source Truth​

Next paths​