YayLayer — a protocol for provable, signed AI code

Own the code your AI writes. Your AI can write a thousand lines while you blink. YayLayer makes every change spec-first and human-signed — so you can prove, in plain language, exactly what you approved. Think of it as a building permit for AI-written code: approved blueprints first, an inspector who checks the build matches the blueprints, and you can’t ship until it passes.

The core idea: sign the promise, not every line

Every unit of code — a Cell — carries a mirrored spec in its comments. You sign the spec’s hash on your phone, so the AI can refactor freely and only a changed promise needs re-approval. A checker proves that the code matches the spec and paints your whole project by state.

• Spec-mirrored Cells: two tracks — machine-checkable claims (ensures, pure, in/out) that can earn Green, plus one plain intent: sentence. Vague prose never earns Green.
• Briefs: each change-set is headed by a Brief — a plain-English record of what you ordered, drafted by the AI, editable by you, and signed together with the specs. Your project’s history, in your words.
• A painted map: Green = code proven to match a signed spec. Yellow = signed but flagged or not machine-proven. Red = mismatch. Unsigned = awaiting you. Pink = code with no spec at all — never hidden.

How it works: spec → sign → build → verify → gate

1. Spec first. The AI writes a Cell’s spec block before any implementation. No code it writes is trusted until the spec is signed.
2. Present a Brief. It drafts a Brief — what you asked for — and presents the change-set with the colour it expects each Cell to earn.
3. You sign on your phone. It runs yay sign; the request appears on your phone. You can edit the Brief, then approve. The private key never leaves the device.
4. Verify. The moment your signature returns, the AI implements the code and runs yay verify — static checks, a behavioural prover, and mutation grading.
5. The gate. CI runs yay verify --strict. Anything Red, Unsigned, or Pink fails the check — it can’t reach main.

The AI can’t cheat — and can’t be told to

Authoring is split from approval by cryptography, not policy. A valid seal is mathematical proof that a human, holding a specific key, approved those exact bytes — not “the AI says it’s fine.”

• The key is only on your phone. Generated on the phone, never on the machine the AI runs on, never in the repo. The AI has nothing to sign with.
• A seal proves a human signed. Every approval is an ed25519 signature over the exact spec hash plus the Brief. Only your phone’s private key can produce it.
• “Approve it yourself” does nothing. Tell the AI — or a prompt injection buried in a web page — to self-approve, and it can’t: there’s no key on its machine. No signature means Unsigned, and the gate blocks it.
• It can’t be changed after. Edit a signed spec, the code’s promise, or the Brief after the fact and the signature breaks — the Cell flips to Unsigned and the gate stops it.

Protected by math: a signature you can’t fake, move, or delete

A YayLayer seal isn’t a signed: true flag anyone can flip. It’s an ed25519 signature — a number only your private key can produce, over the exact bytes of the spec and the Brief.

• Paste a different signature? It won’t verify against your enrolled public key → the Cell flips to Unsigned → the gate blocks it. Forging a valid one means forging your private key or breaking ed25519.
• Edit the code after signing? The hash changes, so the old seal no longer matches → Unsigned. A signature can’t be moved onto different content.
• Enroll your own key? Who-may-sign is an append-only, owner-signed roster rooted in a trust root pinned in CI. Swap the roster or the root and the gate fails.

Think of it as a tamper-evident seal plus a customs checkpoint: nothing enters your trusted codebase without a human signing the manifest. As a side-effect it resists prompt injection — the AI can be told to write anything, but it can’t get that code signed, and un-approved code shows up Pink or Unsigned and is stopped at the gate. It is not an antivirus and won’t stop a change you deliberately approve — the human stays the boundary.

Language support (honestly tiered)

• Fully verified (can reach Green): JavaScript, TypeScript, JSX, TSX — static checks plus a behavioural prover.
• Signed-only (capped at Yellow): Python, C#, Rust, Go, Java, C/C++, Kotlin, Swift, PHP, Scala, Dart, Solidity, Ruby, Elixir. Full spec-mirror, signing, gate and map — but the code-versus-spec match isn’t machine-checked yet, so they never show a false Green.
• Almost anything else: any language whose comments use // or # already works; it just needs its file extension enabled. Spec fields parse comment-agnostically.
• On the roadmap: per-language AST adapters and behavioural proving so the signed-only languages can also earn machine-proven Green.

Recovery — without a backdoor

• Lost the phone, still have the 24 words: on a new phone, choose “Restore from recovery phrase.” The 24-word BIP-39 phrase re-derives the exact same key, so every past signature still verifies and nothing needs re-signing.
• Lost the phone and the words: the key is gone — there is no backdoor. Solo: run yay reroot to establish a new trust root (re-sign the current specs, repoint the CI pin). Team: another owner revokes the lost key and enrolls a new one. Governance never lets the roster drop to zero owners.

Teams

Each person holds their own key; a signed, owner-controlled roster maps keys to names, so every seal attributes to a named human. Adding a signer is a privileged, owner-signed action — the AI can never enroll a key. Private keys never travel between people; you only exchange public keys. Revoking is the mirror, and it refuses to leave the project with zero owners.

Install & signing modes

Requirements: Node 18+ and git. Install once with npm install -g yay-layer, then yay init. Choose how you sign:

• Local: key on this machine, passphrase-encrypted. Simplest, fully offline; least private.
• Mobile, LAN: key on your phone; phone and laptop talk directly over your Wi-Fi. Most private; no third party.
• Mobile, relay: key on your phone; requests travel through relay.yaylayer.com end-to-end encrypted, so it works from any network. The relay only shuttles ciphertext and can’t read your code or forge a signature.

Then instruct your AI once with yay constitution --for <harness> (Claude, Cursor, Copilot, Windsurf, Cline, Gemini, AGENTS.md, or a generic copy) and just ask it to build. Common commands: yay init, yay pair, yay sign --brief, yay verify, yay dashboard, yay adversary, yay gate, yay map, yay adopt, yay enroll, yay revoke, yay reroot.

How it compares

YayLayer is a layer, not a rival. Tests check examples; types constrain shapes; design-by-contract is heavy and rarely adopted; code review is unaided reading with no proof; Copilot/Cursor rules steer generation; git tracks changes. YayLayer adds a human-readable contract, enforces no extra behaviour, requires a signed human review, and gates the result — proving the code matches the spec and attributing approval per unit. It complements GitHub Spec Kit too: drive authoring with Spec Kit, prove and sign the result with YayLayer.

When it’s a good fit — and when it’s overkill

Good fit: shipping AI-written code you can’t fully review line by line; trust and accountability matter (clients, teams, or sensitive code like auth, money, access control); you want a plain-language, signed record of exactly what you approved; you’re vibe-coding but want guardrails against scope creep. Probably overkill: a throwaway script or prototype; solo hobby code you already read every line of; you’re barely using AI to generate code.

Source on GitHub. A protocol for provable, signed AI code.