The method we sell built the platform we sell.

And the log of that build is published here: every decision, every check that failed and every time the system stopped to ask a person. You can download it and verify it yourself, without talking to us.

18 Jun 2026 — 6 Nov 2026 · Log window, in coordinated universal time (UTC).

The question nobody asks out loud

When a firm sells you engineering discipline, there is one objection almost nobody raises in the meeting and everybody thinks: do they actually use this, or do they just sell it?

It is a fair question, and the usual answers do not settle it. A client case can always be qualified. A testimonial depends on who was asked. A demo shows what the seller chose to show.

The only answer that is hard to refute is showing the trail of your own work, unedited. That is this page.

Case zero

None of this was written to show you

What follows is what was left over from building the platform, not a report written afterwards for this page. That is why no figure here is typed in by hand: they are pulled from the build records every time the site is generated, and if the log changes, they change.

days of building: 141 days of building
recorded entries: 1,476 recorded entries
work cycles: 7 work cycles
pieces of functionality: 28 pieces of functionality
distinct agent types: 20 distinct agent types
checks passed: 718 checks passed
checks failed: 42 checks failed
times a person had to approve: 176 times a person had to approve

Where the work concentrated

Each row is a work cycle, identified by its internal code. On the right, the entries it recorded and, in amber, the checks it rejected. Two cycles account for almost everything: they are the ones that built the core.

Recorded entries per work cycle
bc10	713	−39
bc08	459	·
bc11	156	−3
bc06	82	·
bc10-p0-honesty	47	·
bc07	12	·
bc09	7	·

Changing yesterday’s entry breaks every entry since

Every entry in the log carries two fingerprints: its own and the previous entry’s. That chains them together. Deleting one, changing a word in it or inserting a new one breaks the link with everything that follows, and the break is visible.

This is not a promise from us: it is a property of the file you can check on your own machine. Here is what checking it returns:

Chained entries those carrying both fingerprints: 1,153
Fingerprint recomputed correctly recalculated one by one from the original content: 1,153 / 1,153
Links to the previous entry none broken: 1,146

The check found two entries written twice, identical. That is not tampering: it is the same note saved twice. It is counted separately rather than presented as a broken link, which would be misleading, or deleted, which would be worse.

Unedited

The checks that failed are the part that counts

A record with no failures is not a clean record: it is an incomplete one, or a dressed-up one. What follows was in the log and is published as it stands.

42 checks failed

Work that did not pass and had to be redone. Most of it in solution design and in building, which is exactly where you want it to show up: the earlier, the cheaper.
92 loops detected

Times the system noticed it was going round in circles on the same thing and stopped instead of burning more time.
130 gaps in its own log

Moments when the record detected that a note which should be there was missing. A system that writes down its own blind spots is more trustworthy than one that claims to have none.
1 agent aborted

A process that was cut off before finishing and was recorded as such.

None of this flatters us on a first read. It is here because a record containing only successes does not demonstrate rigour: it demonstrates editing.

It judged nothing was probably wrong, and stopped anyway

On 23 July 2026, at 21:22 UTC, the system wrote this down and refused to continue:

Four starts of the same agent with none of them finishing, threshold set at three. Probably an unrecoverable false positive. Do not retry: let a person resolve it.

2026-07-23 21:22 UTC

Read it slowly, because the whole mechanism is in there. The system detected an anomaly, judged that it was probably a false positive — that is, that nothing was likely broken — and still forbade itself from retrying and escalated to a person.

The easy move was to retry. The cheap move was to assume nothing was wrong. It made the expensive one: stop and ask. That decision was written down, with its time and its fingerprint, and it is part of the chain you can verify.

That is what governing engineering with artificial intelligence means when it is not a word on a slide: the moment the machine stops and a person decides.

Do not take our word

Verify it yourself

We are not asking you to trust the summary above. We give you the file and the verifier so you can run it on your own machine.

The verifier is seventy lines, installs nothing and makes no network calls. Read it before running it — reading code before you run it is precisely the habit we are here to install.

01
Download both files

The log and the verifier, into the same directory.
02
Open them and read them

The verifier states what it checks and what it does not.
03
Run it

All you need is Node.js installed.

cadena.json The structure of the log, with both fingerprints for each entry verificar-cadena.mjs The verifier. Read it before running it cadena.json.tsr The timestamp for the file, signed by a third party

node verificar-cadena.mjs cadena.json

What this check does not prove

The verifier confirms the sequence is intact: that nobody deleted, reordered or inserted entries. It does not recompute the fingerprints, because that would require the full content of every note, and that content carries internal decisions and data about the machines the work was done on. The complete record is shared under a confidentiality agreement. Saying so is more uncomfortable than staying quiet about it, and it is the only way the part you can check means anything.

The date

And the date is not ours to set

One fair objection survives all of the above: we serve this, from our own domain. A chain being consistent with itself does not stop it from having been written last week.

So the file carries a timestamp. An independent timestamping authority received only the fingerprint of the file — never the file — and returned a signed token stating that this fingerprint already existed at that hour. Change one byte of the log and the token stops matching.

We checked it both ways before publishing: against the real file it verifies, and against the same file plus one trailing space it fails. A seal that could not tell those apart would be worth nothing.

Timestamping authority: freetsa.org
Sealed on: 2026-11-06 16:40:43 UTC
Sealed fingerprint of the file: sha256 fd23ba0ea8a7bbbeab6ca01b6ae3559d813aa8d58ef17dc0a687390e141a0028
Independently archived since: 2026-11-06 14:22:23 UTC By the Internet Archive, which is not us and does not ask our permission. The link goes to every capture it holds of this address, not to whichever suits us best.

openssl ts -verify -data cadena.json -in cadena.json.tsr \
  -CAfile cacert.pem -untrusted tsa.crt

Both certificates, from the authority itself cacert.pem tsa.crt

Download the authority’s certificate from their site, not from ours: a certificate handed to you by the same party asking you to believe them proves nothing. What the seal proves is that the file existed by then, not that its contents are true. It is one piece of the argument, not the argument.

We publish the structure, not the bodies — and that costs something

Publishing a real engineering trail forces you to decide where the line is. Ours: everything that lets you check integrity is published, and nothing that exposes third parties or the people who did the work.

The text of each note, which mentions internal decisions and, in one case, a test value containing an organisation’s name.
Technical provenance: workstation name and operating-system user of whoever wrote each entry.
The deliverables attached to each step, which are platform code and documents.

And at your company?

If your team already builds with artificial intelligence, the question is not whether it goes faster. It is whether in six months you will be able to reconstruct why the software ended up the way it did. Thirty minutes, no canned demo.

Let’s talk about your flow