Why start here?
The moment documents, metadata, and versions become business-critical, file storage stops being enough. The system needs one place where content stays governed, versioned, and recoverable later on.
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.
Content stays part of the system
Status Available now README sync 22 May 2026
When do I need this?
Loom becomes important when content must not only be stored, but used, verified, and recovered reliably in day-to-day operations.
- when multiple teams need to share the same documents with versions and metadata
- when governance, retention, and access must not dissolve into folder chaos
- when content has to participate in workflows and evidence paths instead of just sitting around
What role it plays here
Loom is the content runtime of the system. It turns documents into governed operating objects with state, metadata, versioning, and explicit boundaries instead of treating them like loose attachments.
What the module actually does
Loom is not just about storage. Its strength is keeping the entire path intact from content intake to a verifiable content state.
At the core
Runs the canonical content runtime. Repo, Share, Search, Transform, and the surrounding services stay materialized as one governed operating path instead of a pile of loose components.
Keeps metadata and versioning dependable. Content remains not only readable, but governed together with metadata, versions, and lifecycle rules inside one controlled system state.
Makes runtime state verifiable. Readiness, health, recovery, and restart behavior are not implicit; they stay visible through repo-owned guardrails and verify paths.
Connects content cleanly into the stack. Loom stays aligned with Fabric, Heddle, and runtime boundaries so content logic does not turn into shadow truth next to governance, identity, and ingress.
What role it plays in the stack
Within the wider stack, Loom is the layer that pulls content out of the file shadow. Other modules can work against dependable content truth instead of attachments and implicit files.
anchors documents, versions, and metadata inside one governed runtime
gives workflows and evidence paths a stable content reference point
stays clearly separated from identity, ingress, and governance ownership
What this looks like in practice
Loom shows its strength when content becomes an operating capability instead of mere storage.
Content arrives under control
Documents do not land in shadow folders, but in the canonical runtime path.
Metadata and versions stay coupled
The content stays readable together with its state, its history, and its governing rules.
Workflows use the same truth
Other modules work from the same content base instead of local copies or assumptions.
Readiness and recovery stay provable
When runtime or load changes, the content path remains verifiable instead of speculative.
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 is intentionally out of scope
Loom is intentionally the content runtime, not the place where other domain truths get reinvented.
not its own identity or SSO owner
not a replacement for Fabric governance or OpenClaw-Env ingress truth
not a loose file silo without runtime and verify responsibility
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.
README.md
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
Within the wider stack, Loom is the layer that pulls content out of the file shadow. Other modules can work against dependable content truth instead of attachments and implicit files.