I build open-source, product-shaped tools for learning, knowledge work, agentic teamwork, and trustworthy automation.
The visible layer is Rumble: products people can use. Underneath, Bolt, Wrench, and Gear form a deterministic, sovereign forge for orchestration, inspection, memory, release, and provenance.
| If you want to... | Start with | Status |
|---|---|---|
| see the public product surface | rumble-cos | usable |
| try the feed-to-knowledge pipeline | rumble-feed-mind | dojo |
| inspect the orchestration core | cos-matic | usable |
| explore DB/security evidence | wrench-db-inspect | dojo |
| understand the whole stack | ecosystem/status.md |
live cockpit |
Rumble projects are the product layer: the things people can read, run, touch, or eventually use directly.
| Product | Purpose | Maturity | Scale-ready? |
|---|---|---|---|
| rumble-cos | education blog and public knowledge surface | usable |
partially |
| rumble-feed-mind | intelligent feed/watch pipeline | dojo |
no |
| rumble-lm | grounded learning sessions and facilitation | contract-first |
no |
| rumble-canvas | product-conception workspace | contract-first |
no |
| rumble-crew | agentic teamwork board | contract-first |
no |
| rumble-note | local-first personal knowledge | contract-first |
no |
scale-ready is not a maturity status. It means deployment, observability, security boundaries, and operational constraints are explicit enough for broader use.
The forge layers exist to make Rumble products reliable without turning every product into a monolith.
| Layer | Role | Main repos |
|---|---|---|
| Bolt | safe orchestration, plans, gates, evidence | cos-matic |
| Wrench | inspection, validation, extraction, reports | wrench-loader, wrench-db-inspect |
| Gear | memory, artifacts, release, provenance, supply-chain | gear-memory, gear-depot, gear-cable |
Detailed status, maturity vocabulary, caveats, and verification commands live in ecosystem/status.md. The target self-improving loop is described in ecosystem/loop.md.
- Products first. Rumble is what people touch; the forge exists to make it reliable.
- Determinism over magic. Reproducible outputs, no silent overwrites, no hidden state.
- No silent failures. Failure modes should be explicit, inspectable, and testable.
- Sovereign by default. Self-hostable, permissive OSS, no unnecessary vendor lock-in.
- Evidence over claims. Maturity, releases, and decisions should point to tests, fixtures, CI, ADRs, or demos.
This ecosystem dogfoods its own forge discipline:
- spec-contract workflows validate ecosystem schemas and fixtures;
- forge-health checks track repository workflow conventions;
- maturity and known limits are tracked in
ecosystem/status.md; - contribution paths are documented in
CONTRIBUTING.mdandROADMAP.md.
Contributions are most useful when they improve docs, examples, fixtures, tests, error messages, or small well-scoped behavior. Larger architecture or product-scope changes should start as design discussions.
- LinkedIn — linkedin.com/in/constj
- Open to discussing sovereign/self-hosted AI, Rust tooling, agentic systems, and reliable software for regulated environments.
Building in the open. MIT · Rust · ADR-driven · deterministic. No silent failures.