Home/Projects
Projects

What we build when nobody is paying us to.

These are the places the data-centric idea gets tested in public. Each one is open source, each one links back here, and the consulting draws on all of them.

regulator

Released · 0.1.4
An agent harness with an explicit cybernetic control plane

regulator asks whether Stafford Beer's Viable System Model can be made operational inside an autonomous software-development system, not as five chatbot personas but as explicit functions, authority boundaries, typed channels, verification gates and feedback loops. It provides its own orchestrator to find out. The premise it runs on: prompts advise, types describe, gates enforce. Every rule lives at the strongest level that can hold it, and every regulator is a registry record that names the failure it absorbs, where it is enforced, its tests and its stated limitations.

Built on Pi, published to npm as six packages under Apache-2.0, and the reference build the Viable Agents course is written against.

The loopcontract → dispatch → verify → route → close, with leases, budgets and worktree isolation
EvidenceHost-run checks at a revision. The model's account of its own work is never the only layer.
IdentityInvariants, glossary and boundaries are files under S5 authority that no unit can write.
MeasuredAn eval harness with declared arms and per-regulator ablation decides whether a regulator stays.

Viable Agents

Course · pilot
Build your own agent harness

Most agent courses teach you the buttons. This one teaches the control system, and you leave holding a harness you wrote yourself. A primer on cybernetics, fifteen modules, a lab with checkpoints, and a capstone, each module opening with a regulatory question an autonomous agent forces on you and ending with the mechanism that answers it, built against regulator.

FormatsSelf-paced, a six-week cohort, or a two-day team intensive on your own repository
ForEngineers running agents on real codebases, platform teams, agent-tool builders, technical leaders

SemanticSeams

Proof of concept
One RDF graph is the source of truth; diagrams are views

Every tool that draws software draws one layer. SemanticSeams puts every element of every layer, a C4 container, an IFML view component, a BPMN task, a DMN decision, a SHACL shape, in one RDF graph as a resource with an IRI, and treats each diagram as a view over it. Click a container and land on its interaction model; click a UI event and land on the process it triggers; click a business-rule task and land on the decision table. The cross-layer edges are the seams, a bridging ontology of 25 predicates, and because it is one graph, the questions no single-notation tool can answer become SPARQL.

This is where the RDF practice and the company name meet: a model of the software, from which the software is a projection.

The descentC4 → IFML → BPMN → DMN or SHACL, by clicking, over a hand-authored model
QueriesWhich UI events can eventually write this shape? What breaks if this node goes away?
Under testCI validates the examples against the shapes and asserts exact rows for every canned query

semantic-stack

Tooling
A Docker stack for working with RDF, ontologies and SPARQL

The local environment behind the consulting work and the one SemanticSeams is developed against. One docker compose up gives you two SPARQL stores (QLever and Apache Jena Fuseki), data transformation with OntoRefine, OpenRefine and the RML Mapper, ontology visualization with WebVOWL, Linked Data browsing with Trifid and Blueprint, and query tooling with RDF4J Workbench, YASGUI and a federated Comunica endpoint.

StoresQLever, Fuseki, and an Oxigraph variant
ToolsOntoRefine, OpenRefine, RML Mapper, WebVOWL, Trifid, Blueprint, RDF4J, YASGUI, Comunica
Working with us

The projects are the portfolio.

If any of this is the problem you have, the shortest route is a call. We'll tell you plainly whether the approach fits.