How to write a blueprint

A blueprint lets another person's AI start from research you already did: the decisions, the dead ends, the checked facts and the numbers behind a product, company, program structure or workflow. It is not a pitch and not a summary. Keep what someone would otherwise spend hours rediscovering, and drop the chatter.

The quickest way: let your AI draft it

Connect Vander Labs to your AI on the Connect page.
In the conversation or project you want to publish, ask: "Turn this project into a Vander Labs blueprint and save it as a draft."
Your AI calls the connector's blueprint_guide tool for this format, writes the blueprint, shows it to you and, once you agree, saves it with draft_blueprint. It lands in your studio as a private draft.
Read it there. Correct anything that is wrong, especially the evidence tags and the stage. Then press Submit for review.

The connector refuses a draft that still contains an API key, password, token, connector URL, email address, phone number or ID number, and tells your AI what to remove (never the value itself). It can not spot everything, such as the names of private people or customer details, so read the draft before you submit it. Your AI can not publish anything: only you can submit, and only a reviewer can publish.

The file

A blueprint is a SKILL.md file. It starts with front matter (a name equal to the blueprint id and a description that tells an AI when to load it), then the title ending in "(R&D blueprint)", then a short note on how to use it. The studio's template has all of it.

These sections, in this order:

Context: when it was researched, the market, the budget, the team and the stage.
The problem: who has it, how they deal with it today, and why that is not good enough.
Decisions: one ### heading per decision, with what was decided, why, and what lost.
Dead ends: one ### heading per idea that was tried or considered and dropped, with the reason and the evidence. This is the most valuable part.
Facts checked: one list item per fact, with its source link and the date you checked it.
Numbers: the key figures and the arithmetic behind them.
Open questions: what is still unknown, and how to find out.
Re-check before relying: prices, rules and platform features that change, and where to check them.
How to apply this: the questions to ask a new person and the steps to adapt the blueprint to them.

Context, Decisions, Dead ends, Facts checked, Re-check before relying and How to apply this are checked before a blueprint can be submitted.

Evidence tags

Tag every decision, dead end and fact:

[verified]: checked against a source, linked, with the date.
[tried]: tested in practice, by you or the project.
[hypothesis]: reasoned or assumed, not tested.

Never upgrade a tag to sound more certain. A careful blueprint full of honest hypotheses is more useful than a confident one that turns out wrong. The page shows the counts, so members see at a glance how much is proven.

Stage and dates

Stage: Research only, Built (not launched), Launched with users, or Earning revenue. Use the true one.
Researched on: when the research was done.
Re-check by: when it should be checked again, usually 3 to 6 months later. After that date the page and members' AI say it is due for a re-check.

Leave out

Secrets and personal data: keys, passwords, tokens, connector URLs, emails, phone numbers, ID numbers, names of private people, customer data, account ids.
Anything illegal or built to deceive.
Medical, legal or financial advice given as instructions. Describe the rule you found, cite it, tag it, and tell the reader to check with a professional.

Before you submit

Every [verified] fact has a link and a date.
Every dead end says why, with evidence.
The stage on the page matches the file.
Anything that changes is under Re-check before relying.
The page fields are filled in: title, subtitle, summary ("Use when ..."), three lines on what the reader's AI starts with, and the key decisions.

Blueprints earn royalties the same way skills do: see Earnings.