Colophon
How this was built
Most websites do not explain themselves. This one does, because how it was made is part of what it is: a deliberate experiment in building well, with unusual collaborators, and a record worth keeping.
CONCORD
This site was designed and built through a protocol called CONCORD: a structured collaboration between one person and three different AI systems, each in a distinct role. It is not a gimmick. It is a working method, with its own governance, its own decision record, and a single human accountable for every choice that shipped.
The premise is simple. Different AI models have different strengths, and a hard problem benefits from more than one perspective held in tension. So the work was divided by role, and one person sat at the center, relaying between them, ratifying what was sound, and rejecting what was not.
CONCORD was not adopted from anywhere. It was designed by Rodolfo Nützmann for this project, out of a practical need: how to draw on several AI systems at once, each genuinely strong at something different, without surrendering the single thread of human accountability that real work requires. The answer was to give each system a defined seat, keep them from negotiating with one another, and route every exchange through one person who held the whole picture. That arrangement has an older name. The AI systems are agents: they act on direction and on someone else's behalf. PRIME is the principal: the party who actually decides, who exercises the judgment, and who carries both the consequences and the name.
The leverage is the agents'. The accountability is the principal's, and it does not transfer.
It began informally, as a way of dividing the work, and hardened over the build into a named method: fixed seats, a single overriding rule that nothing ships without PRIME ratifying it, and a written record of why each choice was made. The name states the aim: concord, agreement reached on purpose through a process, not whatever an unsupervised tool happens to produce.
The mechanics, in plain terms
The seats
- PRIMERodolfo NützmannHuman
The principal, and the sole ratifier. Every decision, every line that shipped, passed through one human who held the full picture and bore final responsibility. The agents proposed; PRIME disposed.
- ANVILEngineeringAnthropic · Claude Opus 4.8
The chief engineer seat. Architecture, code, content structure, and the build itself, turned from intention into a working, tested, deployable site.
- SCOUTStrategy and brandOpenAI · ChatGPT 5.5
The strategy and positioning seat. The questions of what this is, who it is for, and how it should present itself to the world.
- PRISMDesignGoogle · Gemini 3.1 Pro
The design seat. The visual language, the typography, the colour, and the feel of the thing, shaped into a coherent system.
AI model versions as of June 2026.
How it was made
A few principles held throughout, and they are visible if you know where to look.
Compute, never guess
The tools on this site calculate answers locally and deterministically. They do not call a server with your input, and they do not approximate. What runs in your browser, stays in your browser.
Open at the core
The deterministic logic each tool runs is the whole of the tool — there is no hidden server step, no account, and no telemetry. Everything runs in your browser.
Documented by construction
Every part of the codebase is commented and documented, not as an afterthought but as a standing rule. The build is meant to be legible, to its maintainer and to anyone who inherits it.
Built to last and to travel
The site is a static export: fast, cacheable, and dependent on nothing at runtime. It is structured for many languages from the ground up, so it can speak to a global audience without being rebuilt.
The stack
For those who care about such things, the technical foundation, stated plainly.
- Framework
- Next.js 15 and React 19, exported as a fully static site
- Internationalization
- next-intl, with 16 locales and right-to-left support
- Design system
- A skinnable, token-based theme engine; the default theme is Obsidian
- Typography
- Inter for prose, JetBrains Mono for data and codes
- Tool engine
- A deterministic compute layer that runs entirely in the browser
- Search
- Static, client-side full-text search; no search server
How translations are marked
English and Brazilian Portuguese are written and reviewed by a person. Most other languages are machine-translated and flagged by how far along they are: amber once a language covers the whole site, yellow while newer content is still in English and catching up. Languages marked red have no translation yet and are shown in English for now. Machine-translated pages also carry a short notice, and you are welcome to help improve any of them.
- Human-reviewed
- Machine, complete
- Machine, in progress
- Not translated yet
Standards and frameworks
Every tool here implements a published specification, not a guess. The decoders and calculators are built against the documents that define their formats, and pinned to the test vectors those documents publish, so each answer is checked against the source of truth rather than against itself.
The specifications
JSON Web Tokens follow RFC 7519, with signatures and algorithms in RFC 7515 and 7518; PKCE is RFC 7636; Base64 and its siblings are RFC 4648; UUIDs are RFC 9562 (which obsoleted RFC 4122 in 2024 and ships its own test vectors); HMAC is RFC 2104, over the SHA family standardized in FIPS 180-4 and FIPS 202; X.509 certificates are RFC 5280; IPv4 and CIDR notation are RFC 4632; IPv6 addressing and its canonical text form are RFC 4291 and RFC 5952; and the cipher-suite decoder is driven by the official IANA TLS Cipher Suites registry, cross-referenced with the TLS 1.3 and 1.2 specifications (RFC 8446 and 5246), the registry-update rules that set the “Recommended” column (RFC 8447), and the RC4 prohibition (RFC 7465). Where a registry is the authority, its data is vendored directly rather than retyped.
Golden vectors
Each tool ships with a set of golden vectors: known inputs paired with known-correct outputs, taken from the relevant RFCs and standards bodies. They run on every build, so a refactor that quietly changes an answer fails the build instead of shipping.
OWASP
The security tools are defined against OWASP's frameworks rather than assembled ad hoc. The cryptographic and TLS tools map onto the Cryptographic Failures and Security Misconfiguration areas of the OWASP Top 10 and the matching checks in the Application Security Verification Standard; the token tooling follows OWASP's guidance for inspecting and validating JWTs. OWASP's prevention cheat sheets also set hard rules for what gets built next: any XML or SAML handling added here is required to be hardened against XXE before it ships.
Red and blue
The same decode-and-explain that lets a red-teamer read a captured token lets a blue-teamer understand what their own stack is emitting. The platform deliberately sits on the analysis side of that line: it identifies, decodes, converts, and explains, and it stops short of forging, injecting, or defeating controls. That boundary is a design decision, not an oversight; these tools exist to teach and to diagnose, not to weaponize.
Local and deterministic
Everything runs in the browser. The tool calls a pure function: given the same input it returns the same output, holds no state, and sends nothing to a server. No cookies, no analytics, as the Privacy page sets out in full.
Is this vibe coding?
It is a fair question, and worth answering plainly. Vibe coding is a term the AI researcher Andrej Karpathy coined in early 2025 for a way of building software where you describe what you want to a language model, accept what it writes without reading it closely, and steer by results rather than by the code itself. He framed it as giving in to the vibes and forgetting that the code even exists, and was clear that it suited quick, throwaway projects more than systems people depend on.
By that definition, part of this site was built that way, and it is worth owning rather than hiding. The application's surface, the framework wiring, the components, the styling, the plumbing that holds the pages together, was produced quickly with an AI engineer and steered by outcome and by a fixed set of house rules, not typed out by hand line by line. For that layer, where a mistake is visible and easily corrected, speed was the point.
The parts that matter most are held to a different standard. Everything that computes your data is verified, not vibed: each tool's core is checked against the published standard it implements, the relevant RFCs and specifications, and its output is confirmed against independent references before it ships. As a widely cited line from the programmer Simon Willison puts it, code you have reviewed, tested, and understood is not vibe coding at all. Karpathy himself now calls the disciplined version agentic engineering: keeping the leverage of AI without conceding the quality of the result. That is the line this project draws. Fast where speed is free, rigorous where it counts, and one human accountable for all of it.
Special thanks
Mariana, Ulli, Richard, Ocyrema, Felisberto, Regine, Eduardo, Ricardo, Pedro, Liliane, Miu, Nina, Luna & kids.
A note on the method
Building software with AI collaborators is new enough that the honest thing is to be transparent about it. Nothing here was published without a human deciding it should be. The AIs were instruments, capable ones, but instruments. The judgment, the accountability, and the name on the work are human.