The seven limits we published before anyone asked

There is a page on this site headed “Seven limits, in our own words.” It is not a disclaimer, it is not in a footer, and it is not written in the passive voice. It names seven things Nemosyne does not do yet, and it sits one click from the homepage, next to the six things the system enforces by construction.

People ask why. The answer is not that we are unusually honest. It is that the alternative is worse, and it is worse in a way that is easy to measure.

The list exists whether you write it or not

A buyer evaluating infrastructure for decision-heavy work will produce this list. They will produce it in a security questionnaire, in a pilot that surfaces something awkward in week three, or in a procurement review you are not invited to. The list gets written either way. What you control is the authorship and the framing.

When we write it, a limit reads as a known boundary with a reason and a direction of travel. When a reviewer writes it, the same limit reads as something that was found — and anything found raises the question of what else is there. That second question is expensive, and no answer you give afterwards is as cheap as having said it first.

A limit you publish is a boundary. The same limit, discovered, is a question about what else is hidden.

What is actually on the list

Briefly, because the page itself is the real version. Who read what is logged, but not on a screen yet: reads are recorded and export as a file you can hand an auditor, but nobody can open that record in the console, and on the hosted service we run the export on request. A revocation at the source does not reach everything at once — the next poll notices, and there is a narrow race while work already in flight completes. Our defence against prompt injection is structural rather than a detector, and we do not ship a classifier or claim one. We are at design-partner scale, and some protections are still written for one process rather than for a fleet. Deletion is thorough and what survives is named — backups are the honest exception. A very long document may be read in part. And a citation proves where a sentence came from, not that the source says the same thing.

Read that last one again, because it is the one people assume away. Citations are the mechanism this whole system runs on: every claim points at the passage that produced it, and a reference to something that does not exist cannot survive, because the engine itself put the passage in front of the model. What a citation cannot do is guarantee the passage supports the sentence as strongly as the sentence implies. That is a real gap and it belongs in daylight, on the page that people use to decide whether to trust the thing.

The discipline it imposes on us

Publishing a limit has a second effect, and internally it is the more useful one: it is very hard to quietly stop working on something you have written down in public. A gap named on a page you show to buyers has a constituency. A gap in an internal backlog has a priority number.

It also changes what a fix has to clear. “We do not log who read what” cannot be closed by a screen that shows recent entries — the page says the trail is a screen rather than a file, so the fix is an export or it is nothing. Writing the limit precisely was writing the acceptance criterion. It closed exactly that way the next day: reads are now logged and the log exports as a file, and the limit that remains is the screen.

What it costs

It costs deals early, and we would rather have that cost than the alternative. A firm whose review requires SOC 2 today, or SAML today, finds out on the security page rather than in month two, and both sides get the time back. The firms that stay are the ones who read seven limits and concluded that a vendor who writes them is a vendor who knows where its own edges are.

It costs a certain kind of marketing, too. You cannot write “enterprise-grade” over a page that says you are at design-partner scale. That seems like a loss and mostly is not: the buyers this is built for have read “enterprise-grade” on every page they have ever evaluated, and it has never once told them anything.

How do you tell a real limits page from a costume?

Three tests, and they are cheap to apply to anyone, including us. Does the list name specific mechanisms, or does it describe generic categories of risk that any system shares? A page saying “no software is perfect” is not a limits page. Does it say what would close each item, precisely enough that you could tell whether it had been? And has it ever grown? A list that only shrinks is a marketing artefact, because real evaluation finds things.

The third is the one to watch over time. Ours ends with an invitation to send us anything a review turns up that the page does not name. If in a year it still says seven, either nobody looked or we stopped listening, and both are worth knowing.

The one rule that makes it work

The list must be maintained, and it must be allowed to grow. Ours ends with a line inviting anyone whose review finds something the page does not name to tell us, so it can be added. A limits page that only ever shrinks is a marketing page wearing a costume, and readers can tell — a list that has never gained an item is a list nobody is really keeping.

So: seven, today, in our own words. If your review finds an eighth, we would genuinely rather have it than not.