Skip to content

OSS Inventory v2: Unifying Open Source Accounting Across the Stack

Today marks the platform-wide adoption of a canonical OSS inventory contract v2, transforming open source dependency tracking from a patchwork of local conventions into a single, queryable source of record. This change unlocks precise compliance, simplifies due diligence, and automates reporting for every operator and integrator building on Helpifyr and JaddaHelpifyr.

Jadda Helpifyr3 min read
OSS Inventory v2: Unifying Open Source Accounting Across the Stack

At a glance

248

merged changes

42

code projects involved

Most changes in

  • jhf-spindle20
  • jhf-openclaw-env19
  • jhf-shuttle17

Underlined terms are explained: just hover or tap.

Imagine a critical security bulletin drops for a widely used open source library. Previously, every team scrambled through divergent inventory files, manual spreadsheets, or bespoke scripts to find out where that library even lived in the stack. Mismatches and omissions were routine, and compliance reporting was a recurring fire drill. Today, that friction collapses: every major component, from Boosts to core JHF services, now declares its OSS footprint using a unified, versioned contract. The new system doesn’t just centralize data-it enforces a standard that is machine-verifiable and ready for automation.

Why This Day Mattered

By converging on a single, canonical OSS inventory contract, the platform now guarantees that every open source dependency is discoverable and auditable in a uniform way. Operators can answer compliance questions instantly, security teams can automate vulnerability sweeps with confidence, and integrators can build tooling that works everywhere without per-repo adaptation. This is not just about regulatory checkboxes: it unlocks real-time risk assessment and simplifies onboarding for partners and customers who need to prove software provenance.

The closed UTC day 2026-08-25 resolved into 248 merged PRs across 42 repos, led by jhf-spindle (20), jhf-openclaw-env (19), jhf-shuttle (17).

What Actually Changed

Every major repository in the Helpifyr and JaddaHelpifyr ecosystem migrated to the v2 OSS inventory contract. This contract is not just a file format: it defines required fields, versioning, and validation logic that CI enforces on every change. The contract is machine-readable, version-pinned, and exposes a stable schema for both human and automated consumers. The adoption was not piecemeal-CI and workflow guards now block non-compliant merges, and inventory generation is standardized across the stack, ensuring drift and omissions are surfaced early.

Why It Holds Better Now

The new contract is enforceable by CI, eliminating silent drift and hand-maintained lists. Its schema is designed for composability, making it trivial to aggregate inventories across services or environments. By pinning to a versioned contract, the platform can evolve inventory requirements without breaking consumers, and every repository’s OSS footprint is now provably up to date. This closes gaps that previously allowed for shadow dependencies, incomplete disclosures, or inconsistent audits.

Want to Know More?

How will this canonical inventory foundation power automated license compatibility checks, or enable real-time security notifications for every deployment? What new platform features become possible now that open source provenance is a first-class, queryable contract?

Terms in this post

drift
Target and actual state silently moving apart.
provenance
Proof of origin: where a piece of information or an artefact comes from.
PR
Pull request: a reviewed code change that gets merged into the project.
repo
Repository: a code project under version control.
operator
The person or team running the system.

What would this look like in your company?

A pilot shows it with a real process.

Request a pilot

More on Compliance and legal

See all
Immutable Compliance: Locking Down the SELVAGEv4.3.1 Kernel as Source of Legal TruthCompliance and legal

3 min

Immutable Compliance: Locking Down the SELVAGEv4.3.1 Kernel as Source of Legal Truth

Today's platform advance cements the SELVAGEv4.3.1 compliance corpus as an immutable, CI-enforced reference, transforming legal and regulatory posture from a mutable artifact to a provably fixed contract. This shift guarantees every downstream validation, deployment, and audit operates against a single, authorized baseline-eliminating ambiguity and accidental drift.

Read
Fail-Closed OSS Service License Policy: Enforcing Real Boundaries for Third-Party ComponentsCompliance and legal

2 min

Fail-Closed OSS Service License Policy: Enforcing Real Boundaries for Third-Party Components

A new fail-closed license policy for OSS services now makes it impossible for unlicensed or misdeclared third-party components to silently ship in Helpifyr. This update turns license compliance from a best-effort check into a strict runtime gate, raising the bar on operational safety and legal clarity for everyone who builds or operates on the stack.

Read