enrichme·ai
GitHub → Work with us

Open infrastructure for the AI era

Agents are doing the work. Someone should be able to check.

Cistern governs what agents read of your data. Penstock records what an agent did. Both Apache 2.0, both self-hostable, neither announced before it ran.

Software is increasingly written and run by agents. That is a good thing, and it holds only if the work stays as accountable as it was when people did it. You should still be able to see what touched your data, under whose authority, and take it back. EnrichMeAI builds that accountability in the open, at both ends: the data side, where agents must ask before they read, and the agent side, where what an agent did is written down. Embed it, self-host it, or have us run it. Nothing here is announced before it runs.

Explore Cistern → Read the source →
Shipping now
Cistern
v0.2.0 · GHCR
Penstock
v0.2.0 · signed jar
Culvert
PyPI · Maven
Licence
Apache 2.0
What we build01

Accountability at both ends, and the frameworks underneath.

An agent reading your data and an agent writing your code are one problem seen from two sides: work is being done by something that does not remember, does not explain itself, and cannot be asked afterwards. Cistern answers for the data: every read permitted in advance, and receipted after. Penstock answers for the work: every model call and tool invocation written down. Those two are the AI-era work; Culvert, below, is a data-pipeline framework with no AI in it, and it is here because it is where the practice these two are held to was proven.

01 The data side v0.2.0 · live

Cistern

the gateway between AI agents and your data · open & self-hostable · Java · Apache 2.0

Cistern stands in front of what's yours, and makes every application and AI assistant ask permission instead of taking copies. The owner writes the rule (this assistant, this folder) and Cistern enforces it on every request, revokes it on the very next one, and leaves a receipt of every allow and deny. Built in the open on open specifications: Solid for the data and its access rules, and an MCP front door so any assistant that speaks it reaches the pod through the same enforcement as everything else. No vendor sits between you and your own decisions.

Receipts, not claims
  • +docker pull ghcr.io/enrichmeai/cistern:0.2.0 is live on GHCR. It runs enforcing with three environment variables
  • +Held to a stranger test before it was named here: pull, run, grant, refuse, revoke, receipt, from the published artifacts alone, with 1,987 green tests behind it
  • +Every decision is receipted, literally: who read what, under which rule, when, queryable by the owner
  • +Apache 2.0 · built against the official Solid conformance suite, score public and only moving forward · limitations stated plainly in the release notes
Explore Cistern → Release v0.2.0 → Source →
02 The agent side v0.2.0

Penstock

the agent that does the work, and the reference client for governed access · Java · Spring Boot

Copilot beyond the IDE: an agent an organisation runs itself, driving the workflows an editor cannot reach (CI hooks, chat commands, scheduled triage) against its own internal systems. It keeps the record its work deserves: every model call and every tool invocation is written to an audit log the owner reads back.

It earns its place here by being the first thing to ask Cistern for something. An agent that wants a file has to present an identity of its own, receive only what was granted, be refused the rest, and leave a receipt behind. The shape of that exchange is the same whether the agent is writing code, reading a case file, or doing something nobody has built yet. Proving it on an agent we run ourselves is how the pattern gets settled before anyone else has to depend on it.

v0.2.0 is live: a signed jar, a bill of materials, and a multi-architecture image. It has not yet cleared the stranger test Cistern is held to (deploy and use it from the published artifacts alone, following only the shipped docs), so it is a thing to run on your own machine for now, not to put on a network.

Where it stands
  • Todaythree surfaces (web, REST, streaming), pluggable models including a local one, and an audit log of every model and tool call, attributed to the authenticated user and readable in the app
  • Nowthe pod tool has shipped: Penstock asks a Cistern pod for a file over plain HTTPS as its own principal, is refused outside its grant, and what it read is receipted on the owner's side. Any client needing scoped, accountable access to someone else's data follows the same shape
  • Laterthe stranger test. Everything with a fix available has been fixed: across four releases, 138 findings down to 85 and the criticals from fourteen to one. That one is waiting on an upstream release that does not exist yet, so there is nothing to apply. Every scan is attached to its release, so the whole series is yours to read rather than ours to claim
Explore Penstock → Source →
03 A separate line data infrastructure

Culvert

cloud-agnostic data-pipeline framework · Java + Python · Apache 2.0

Data pipelines defined once against a language-neutral contract set, then run on any cloud by swapping adapters instead of rewriting logic. Shipped on PyPI and Maven Central, after a real deploy caught eight bugs that 1,145 green tests never saw. The full account, contracts through honest status, is on its own page.

Explore Culvert → Source →
04 Tooling alpha · unpublished

enrich-test-api

cloud tests that never name a cloud · Java 17 · Apache 2.0

A Java test asks for a bucket or a queue and gets one, backed by a container the library started. The capability interfaces carry no cloud SDK, so a test compiled against them has no compile-time knowledge of a provider, and the AWS SDK is found at runtime through Java’s own ServiceLoader.

It exists because the usual options are a mock that passes whether or not the code is right, or a real account that is slow, costly and unavailable offline. Running against a local emulator lets a test fail for a reason that matters.

This one is earlier than the rest of the register and its page says so throughout. Four capabilities work against AWS on LocalStack; the release path to Maven Central is built and nothing has been tagged, so nothing is published yet; coverage sits below its own branch target and the floors the build enforces have not yet been raised to the new measurement.

Where it stands
  • Todayfour capabilities against AWS in emulator mode: object storage, queue, publish/subscribe and a NoSQL table. A plain verify on JDK 17 runs 36 tests, including eleven integration tests and seven Cucumber scenarios against LocalStack, with formatting, style, dependency convergence and coverage floors all enforced. The multi-test-class case it is aimed at, which used to misbehave, now cleans up after every class
  • Honestlyone provider, so the portability claim is a design intention rather than a demonstrated property. Emulator only. Nothing published yet: the release path is built and waits on a tag. Branch coverage 0.67 in the core against a 0.70 target and 0.44 in the adapter, and the floors the gate enforces are still the older measured values, so the number can slip back to them before it can slip further
  • Laterthe first tag, 0.3.0-alpha1, once the Portal credentials exist. Then a second adapter, which is the only thing that can prove the seam holds, the coverage floors, and a live mode that needs a credential story before it means anything
Explore enrich-test-api → Source →
05 · reserved

The next framework

The register is open-ended on purpose. Each new framework takes the next number and the same treatment: what it is, where it stands, and what a stranger can run today.

These grow slowly on purpose: nothing is named here before it has run on real infrastructure, and what has not shipped says so.

Where this goes02 · direction, not release

Community pods: data held by the people it is about.

Nothing here has shipped. It is written down so you can see what the released work is for.

A pod per person is the easy half. The harder and more useful case is a pod a community runs for itself: a union, a patient group, a co-operative, a neighbourhood. There the data is about many people at once, and the rules over it are decided by them rather than for them.

That needs three things underneath: an owner who can be more than one person, rules that survive a change of membership, and a record every member can read. Cistern already enforces and receipts; what a community adds is who gets to write the rule in the first place.

It is the direction the released work is pointed at. Nothing of it is built, and this page says so rather than dating itself against a release.

How you run it03

Open on your terms, too.

Embed

Add the dependency, own the stack. The frameworks are ordinary libraries in your build. No agents, no server, nothing phoning home.

Self-host

docker compose up and Cistern is yours: your hardware, your keys, your rules. Everything it does is inspectable, down to the audit trail.

Run by us

Some teams want the authority without the operations. We deploy, operate, and upgrade it, in your cloud or ours, with the maintainers on the other end of the line. Today that's an engagement, not a sign-up form: talk to us.

How we build04

Code got expensive cheap. Judgment didn't.

AI can write a thousand lines in a minute. What it can't do is stand behind them: keep an interface stable for years, catch the failure the emulator never shows, ship an artifact a stranger can depend on.

Systems rarely break in the middle of a function. They break at the seams: between your logic and the cloud SDK, between the schema Terraform provisioned and the schema the code writes, between what passed on your laptop and what runs on a serialised worker with real IAM. Generated code adds more seams. It doesn't harden any of them.

Good infrastructure is where the hardening lives: a stable contract, a conformance suite every implementation has to pass, honest notes about what doesn't work, and a signed, versioned artifact. None of that is typing. We build our own with AI agents, and it only works because the agents are held to the same contracts and gates.

What got cheap
  • −Lines of code
  • −Boilerplate and scaffolding
  • −First drafts of anything
  • −Plausible-looking implementations
What didn't
  • +Contracts that hold across clouds and years
  • +Tests that catch what emulators can't
  • +Production scars, written down honestly
  • +Signed artifacts a stranger can trust
  • +Consented access to your data
Work with us05

Answer for what your agents did.

The objective is narrow, and it is not a licence pitch: an organisation should be able to let agents work on its data and still answer, afterwards, for everything they touched. Most cannot today, not for want of policies, but because nothing underneath produces the evidence. That is what we build, and it only counts if you can run it yourself. Everything here is Apache 2.0, free for commercial use, no strings and no open-core bait.

There is no paid tier holding anything back, and there is not going to be one. Software that decides who may read your data has to be software you can read, so all of it is yours. It keeps being built because the organisations that come to rely on it choose to work with us. That is the whole arrangement, and it is a fair one.

Where we work with organisations directly it is in service of that:

  • Integration engagementswhen the loop has to close inside an estate that already exists
  • Enterprise supportwhen something load-bearing depends on it
  • Sponsored featureswhen a real deployment needs the roadmap bent toward it
  • Managed deploymentsfor teams who want the authority without the operations
Start with COMMERCIAL.md → or open a GitHub issue labelled commercial.
Writing06

The code is one part. The thinking is the product.

Building infrastructure in the open means writing down more than the code: the decisions, the seams that turned out to be load-bearing, and the failures that only production showed. That record is a deliberate output here, not a marketing afterthought. Every technical claim cites the real source tree.

The first long-form piece is a practitioner's account of building one of these systems in the open: twenty-one chapters, in progress, with an essay series alongside it. Read what it covers →

Who is behind this?

Joseph Aruja

I'm Joseph Aruja. Twenty-five years building software for banks and enterprises, too much of it the same scaffolding rebuilt on every new platform. EnrichMeAI is where that experience turns into things other people can use: open infrastructure, frameworks, writing, and the occasional strong opinion. All in the open.

House rule

"Nothing here is announced before it has run on real infrastructure. Claims are cheap now. Proof isn't."