The delay happens before the decision
A month in, the question changed. Registrars did not need to process incomplete applications faster; they needed applications that arrive ready to decide. Everything since follows from that.
Aristotelis Adamidis · · 4 min read

For the first weeks of June we did not write software. We read applications. Old ones, anonymised, lent to us by people who had processed them, and the email threads they came wrapped in — because a registration, as it actually happens, is an email thread. An owner or an agent writes in. A registrar replies with what is needed. Documents arrive in the wrong order, in the wrong version, with a name spelt two ways and a tonnage figure that does not match the certificate two messages up. Someone asks again. Someone waits.
What struck us was not that any single step was slow. Most steps were quick. The registrar who finally sat down with a complete file made the decision in an afternoon. The weeks were spent before that afternoon ever arrived — in the gap between what the flag required and what the file contained, and in the correspondence that closed it one document at a time.
The delay happens before the decision. So the system has to happen before the decision too.
What the observation ruled out.
It ruled out the obvious product: a portal that collects the same emails through a form and puts a logo on the mailbox. A faster way to receive an incomplete application is still an incomplete application, and the registrar still spends the month closing the gap. It ruled out a queue with better reporting, which would tell the registry precisely how long it was waiting without shortening the wait.
And it ruled out the tempting answer — software that decides. A registration is a decision a named officer takes on behalf of a flag, and the flag's authority is the whole point of the thing. Nothing we build will ever approve, reject or issue anything. The machine reads, checks, compares and prepares; a person decides, and the record says who.
What it left.
It left one idea, which sounds small and turned out to be everything: the requirements, the documents and the decision belong in one continuous record, and the owner should be working against the flag's own requirements from the first document rather than discovering them one reply at a time. If a file cannot be submitted while it ignores what the flag requires, and every document is read the moment it arrives, then what reaches the registrar is a file that is ready to decide — and the month disappears from the place it was hiding.

That is where EnSign began. Not with a screen, but with a sentence we kept coming back to, and then with the register itself — which is the next thing we wrote about. The whole road is on the About page; this was its second stop.



