Why start here?
Loom keeps content, versions, and metadata governed inside the system instead of leaving them as loose files.
Content
The place where no document gets lost
The system’s governed content layer.
Loom keeps content, versions, and metadata governed inside the system instead of leaving them as loose files.
jhf-loom is the Helpifyr module for content and ECM runtime behavior. The repository owns the runtime contract, compose baseline, boundary documents, and verification surfaces for the Loom lane.
Status Available now README sync 29 Apr 2026
When do I need this?
Start here when files need to become system components instead of staying somewhere in storage.
What role it plays here
The system’s governed content layer.
Documents are not just files. Without Loom, the system lacks governed versions, metadata, and dependable content paths.
What the module actually does
It turns content into a system capability: versioned, traceable, accessible, and cleanly connected to workflows, evidence, and business context.
At the core
Runs the canonical Loom runtime stack (db, activemq, search, transform, repo, share)
Exposes the Share-first user surface and repository machine surface through the trusted ingress path
Maintains repo-owned runtime guardrails (low-pressure health profile, restart/backoff, idempotent apply, bounded diagnostics)
Publishes machine-readable runtime and boundary contracts in config/runtime/*
Provides deterministic validators and smoke/resilience checks for repo and live posture
What role it plays in the stack
jhf-loom owns:
Loom runtime contract truth for this repo Runtime service composition and low-idle guardrail behavior Repo-side and live verify paths for runtime health/resilience
jhf-loom consumes:
Fabric governance and contract truth (read-only) Heddle identity truth (IdP side) OpenClaw-Env ingress/TLS/runtime exposure truth
jhf-loom does not own:
Fabric shared governance truth IdP realm/client ownership Ingress DNS/TLS ownership
What this looks like in practice
Documents are not just files. Without Loom, the system lacks governed versions, metadata, and dependable content paths.
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
Loom does not stand alone. It connects to neighboring modules so a single capability becomes dependable follow-through.
Important boundary
Loom stays bounded to its role as The system’s governed content layer. It does not replace other modules; it makes its part of the system traceable, connectable, and reviewable.
What comes next
Fabric Contract, projection, and governance truth for the stack. Heddle Identity, session, and SSO truth for the stack. Shuttle Workflow execution and operational process motion. Spindle Business truth and operational business logic. Bobbin Persistent memory and provenance 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.
Loom is the runtime for documents, metadata, versions, and governed content lifecycles inside Helpifyr.
It turns content into a system capability: versioned, traceable, accessible, and cleanly connected to workflows, evidence, and business context.
Documents are not just files. Without Loom, the system lacks governed versions, metadata, and dependable content paths.
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-loomLoom
Documents are not just files. Without Loom, the system lacks governed versions, metadata, and dependable content paths.