How much work is this, honestly
Two answers, and you need both. The code is a library call with nothing to install. The work is writing down the standard you already follow — and that half is a meeting, not a deployment.
The part that really is nothing
No runtime dependencies. Nothing to install, nothing to keep patched, nothing that reaches the network on its own.
| Third-party packages the engine pulls in at run time | 0 |
Lines in the worked example that goes from nothing to a sealed record (13-manuals/smoke.js) | 68 lines of code, 91 with its comments |
| Systems you have to replace | none |
| Data that leaves your building during the two-week assessment | none |
| Adapters already written | 5 — ndjson, poll, sse, webhook, websocket |
What does “no runtime dependencies” actually buy me?
It means the thing your security team has to review is one body of code, not that code plus forty packages it pulled off the internet, each with its own maintainer and its own patch cycle.
It also means the engine cannot quietly start talking to somebody. There is nothing in it that opens a connection, so "where does our evidence go" has a short answer: nowhere.
The engine is a library you call. It takes a record, it takes the question, and it gives you back an answer and a sealed receipt. Anything that needs signing takes a callback, because this code holds no keys — yours stay wherever you already keep keys.
The part that is real work, and we are not going to soften it
Writing down the standard is the job. Everything else is plumbing.
- Encoding your first standard — half a day with your quality lead, in week zero. Somebody has to say exactly what a document must contain, whose word counts for it, and how old it may be. In most organisations that lives with the people who know it rather than in a form a computer can check, so somebody has to say it out loud once. That meeting is the product being built, and it is not something we can do without you in the room.
- Deciding where the record lives, and who backs it up. The ledger is a file. It is yours. Somebody in your infrastructure team has to own it exactly as they own any other system of record.
- Key custody. We hold none, which is the point and also the work: your organisation has to decide where signing keys live and who may use them. In a large company that is a change-advisory item, not an afternoon.
- Keeping the register of who is accredited to check what current. If nobody re-issues it, every "independent" finding quietly stops being independent.
- Deciding what happens when it is unavailable. If you put a gate on the path of releasing goods, somebody has to have decided in advance what the dock does when it cannot reach it. That is a decision, and it should be made before the first time it matters rather than during it.
Why are you telling me the hard parts before I have bought anything?
Because you will find them in week two anyway, and a supplier who knew and did not say has told you something about the rest of what they said.
The two-week assessment deliberately touches none of this: nothing is installed, nothing connects to your systems, and nothing is enforced. The list above is what a real deployment costs, and it is on this page so it is not a surprise later.
The full version of this list, with the architectural decision it turns on, is in 13-manuals/INTEGRATION-ENTERPRISE-STACK.md — 11 sections, written for your architects rather than for you.
What the code actually looks like
This is the shape of it, and it is the shape whatever you are integrating with. One capture, one decision, one sealed receipt:
const { SecondBrain } = require('corobate-memory');
// your keys stay yours — the engine holds none, and asks
// you to sign when something needs signing
const brain = new SecondBrain({ keyring });
// a document arrives from wherever your documents arrive from
brain.capture({
subject: 'shipment:RX-1188',
predicate: 'heat_treat_certificate',
actor: 'actor:org:LAB-DE-0447', // WHO observed it
body: certificateText,
});
// the decision your process was going to make anyway
const decision = await brain.act({
subject: 'shipment:RX-1188',
question: 'May this shipment be released?',
critical: yourStandard,
});
decision.verdict // APPROVE, CAUTION or WITHHELD
decision.receipt // the sealed record, ready to send onWhere does that fit in what we already run?
Wherever the decision is already being made — the moment your receiving screen, your ERP or your workflow tool would have said yes. It is a function call in the path you already have, not a portal somebody has to remember to open.
That is deliberate: the failure mode of every compliance tool your team has been sold is that it lives beside the work instead of inside it, and after eight weeks nobody opens it.
A runnable version of exactly this — real keys, a real registry, a real sealed receipt at the end — is 13-manuals/smoke.js, 68 lines, shipped in the manual pack.
What not to put it in front of
An integration page that lists only what a product can be connected to is a sales document. These are the places we would argue against, in your first meeting:
- Anything on a millisecond path. This decides in the time a database query takes, which is fast for a receiving dock and slow for a trading loop.
- A queue that can reorder. The record is a chain. If your messages can arrive out of order, the chain has to be built somewhere they cannot.
- Every decision you make. Start with the one you would least like to be asked about in three years. If that one is not worth it, the rest are not.
Nothing on this page is legal advice.
The dependency count is read from the engine's own package.json, the line count is counted from 13-manuals/smoke.js, and the adapter list is walked from the tree. Nothing on this page is typed.
This page loads nothing from another origin and makes no request at run time.
Nothing here is legal advice.