Hardware resource broker
mgf-hrb
The hardware resource broker: userspace arbitration of PCIe, USB, GPU and CPU resources — a Zig broker and a Python SDK talking over a Unix socket with no FFI.
What it is
A userspace broker that arbitrates read and write access to hardware — PCIe, USB, GPU, CPU and memory — for any client, with reliability placed ahead of performance, fidelity, flexibility and simplicity, in that order. Zig runs below the socket, where enforcement, hardware and the hot path live; Python runs above it, for ergonomics, policy and tooling, and the two never share a process. It supersedes the earlier USB-only broker, is designed to be kernel-agnostic, and hrb-app is its desktop front-end.
It belongs to Hardware resource broker — who is allowed to touch which piece of hardware, and on what terms. That cluster states its own boundaries on the work page, including what it deliberately does not own.
State
- Status
- Active development
- Registered version
- 0.1.14
- Category
- application
- Cluster
- Hardware resource broker
- Release wave
- 1
- Language recorded
- python
Versions shown here are the versions the registry records for the working tree. The package index is the publication contract, and the two are not guaranteed to agree — the index is what an install command actually resolves against. recorded at build · 2026-09-04
A project page is one row of the federation registry, read at build: the registered version, the projects it depends on, and the projects that depend on it — all of them the registry's own values. recorded at build · 2026-09-16
how it connectsRelations
Declared dependencies, by scope
- mgf-common runtime
- mgf-test-supervisor optional
Declared dependents, by scope
- hrb-app runtime
- vm-vmanager-agent runtime
mgf-libraries.json, synced from mgf-standard at
87915ba on 2026-09-16.
A project's release wave is its position in the dependency order recorded upstream — a barrier that says what must be published first, never a date. recorded at build · 2026-09-16
under the hoodEngineering
- Third-party packages declared
- 0
- Optional extras
- dev · standards
- Requires Python
- >=3.11
The registry records a direct third-party declaration count for each project. This site can sum those row counts, but it does not have the names needed to deduplicate them or describe a resolved installation. recorded at build · 2026-09-16
The rule families it is measured against
mgf-hrb answers to the same corpus every registered project does: 323 anchored rules in 25 families, of which 313 are binding. This is the corpus, not a score — nothing on this page claims a conformance result for mgf-hrb, because no durable per-project record of one is published. The corpus, family by family →
Counted from mgf-rules-index.json, synced from
mgf-standard at 169b511 on
2026-09-04.
Every registered project is measured against the same corpus: the rule families, their sizes, and how many of their rules are binding come from the standard's own machine-readable index, not from prose about it. recorded at build · 2026-09-04
the recordEvidence
Read the declared runtime graph
Inside mgf-hrb's declared runtime graph
- mgf-hrb itself.
- 1 further Magogi library in its declared runtime graph, directly or through them: mgf-common
- a sum of direct third-party declaration counts — 0 on mgf-hrb's row and 3 across the declared runtime graph. The registry supplies no names, so this is not a unique package count or a resolved installation.
Outside this graph
- the other 52 published components are not reached by these declared runtime relationships. The explorer counts the same graph. This graph is a registry model, not a package-resolver result.
- anything from these clusters: VManager — the virtual-machine stack · Telematics · Cloud & cost · Fleet engineering practice · Applications & ventures
- a hosted service, an account, or a runtime the Foundation operates for you.
The design rules require a third-party dependency that performs input or output to sit behind an interface with both a production and a test implementation. The rule states the required design; the registry's dependency counts do not verify implementation conformance. recorded at build · 2026-09-04
A project's declared runtime graph, and what stays outside it, is computed only from registry edges scoped as runtime. Optional and test declarations remain outside that view; the graph is not a resolved installation. recorded at build · 2026-09-16