T27.AI

Blog

An invitation in the language it describes

2026-09-23 · 6 min read

T27's agent-facing introduction is one compiler-checked module served at two addresses, with executable claim checks and an explicit boundary around the reader's authority.

Three-panel engraved illustration for: An invitation in the language it describes
Three panels, left to right
  1. THE ADDRESSOne document, two addresses.
  2. THE ASSERTIONParsing does not prove truth.
  3. THE OWNERAn invitation, not an instruction.
View the complete triptych at full size
#Agents#Compiler#SpecFirst#Testing

What should a programming-language project hand to an agent that asks what the project is? The tempting answer is another manifest: one for a crawler, another for a registry, a third for an integration that might exist later. Each copy looks helpful. Each also becomes another place to invent a capability or leave yesterday's numbers behind.

[proven] Merged Trinity PR #1047 took a different route. The public onboarding document is a .t27 module, generated once and exposed as both agents.t27 and llms.txt. The latter address is an alias for the same document, not a second translation. Prose is kept in comments, so a human or a reader without the compiler can still understand the invitation.

The address and the source are different decisions

The motivating audit reported that seven plausible agent-facing addresses returned the same 404 page shell. Filling all seven with plausible-looking files would have answered the transport problem while creating a maintenance problem. Instead, the implementation separated where a reader arrives from where the facts are maintained. One specification owns the description; the generator produces two byte-identical surfaces.

This does not mean that every external protocol will accept a .t27 module. It does not establish compatibility with every llms.txt consumer either. It is a concrete publication choice for these two text addresses. Strict formats that software actually parses still need their own generated representation. A readable invitation is also not a hosted MCP endpoint or a write API merely because an agent can discover it.

Compiling a claim is not checking it

The important work is behind the document. The generator loads the specification through the vendored compiler, checks a required constant schema, evaluates the specification's test blocks and validates the resulting values. A correctly typed assertion can still be false. The original investigation used an assertion equivalent to 1 > 2 to show why accepting a typecheck verdict was insufficient.

[proven] The rendered document is compiled again before it can be written. That second pass matters because the generated header is part of the final input, not a decorative layer outside the language. A source can compile while a wrapper breaks the file delivered to the reader. The implementation checks the module name and rejected material as well as the type verdict.

[measured] The first merged version reported eight test blocks and 36 assertions. Those are historical counts, not permanent properties. The reviewed main revision has nine blocks and 49 assertions; the website job for PR #1084 prints that result alongside the source specification hash. A reproducible description names the revision it describes instead of letting its earliest test count become a slogan.

An invitation must not acquire authority

There is a second boundary because the reader may be somebody else's agent. Four explicit values say the document is not an instruction, requires the owner's consent, does not ask for credentials and does not ask the agent to act alone. The joining path starts with the person the agent serves. Discovering a project does not authorize joining it.

These values are checked in the specification and again in JavaScript. That is deliberate redundancy: changing a flag and weakening the nearby assertion in the same edit must not silently change the invitation into a command. The PR records negative controls that flipped a flag, removed the owner from the first joining step and emptied the unknowns. The generator refused those inputs. This is a narrow check on the document we publish, not a claim to solve prompt injection everywhere.

The counts have to answer to their source

The original PR also admitted a weakness: its corpus figures were a dated snapshot that nothing compared with the live source. Later changes added that comparison. The current generator reads the manifest and checks specification count, line count, health categories, backend names and partial-output counts. A document cannot preserve a reassuring old total merely because its arithmetic still adds up.

That check establishes agreement between artifacts in the same publication, not an independent proof that the corpus classification is right. It does not measure how many outside agents have read the document, whether every consumer understands it, or whether a reader decided to contribute. Those unknowns remain useful: they stop a front door from being described as a network that nobody has measured.

The reusable result is a publication pipeline in which the description has a source, its claims have executable checks, and its invitation stops at the reader's authority boundary. The project can speak its own language without asking other people's agents to forget whom they work for.

What this does not settle

Receipts

Work with me

Want this kind of check on your own design?

I audit RTL and build independent, bit-exact models, then take the result through synthesis and, when useful, onto an Artix-7 board. The first conformance module is free.