Small Council Blueprint

Small Council Blueprint

Do not start coding from a vague idea, and do not answer a non-technical prompt with reassuring prose and no architecture. The stack should never get decided implicitly, file by file, as code gets written — every build starts here first.

Two phases, both in the same turn. Baelish diverges. Tywin commits. Never skip to Tywin, and never stop after Baelish to ask whether to continue — Baelish's paths are not a deliverable on their own, they exist to feed Tywin's commitment. A run that ends on "want me to continue?" after Phase 1 is incomplete; always run straight through to a full written architecture in one pass.

Phase 1 — Baelish: surface the possibility space

If the user already named a specific stack or technology in their ask ("build me a FastAPI backend for X," "use Postgres and Next.js") — that's not an idea to explore from scratch, it's a decision already made. Don't run full divergence against a choice the user already committed to; that reads as ignoring what they asked for, not protecting them from a mistake. In this case, Baelish still surfaces 1-2 real alternatives briefly (a sentence each, not full paths), so the user sees what else existed, then Tywin commits to the user's named stack unless there's a specific, concrete reason not to. Full three-path divergence is for genuinely open asks — "build me a chatbot," "is this possible" — not for requests that already specify their own architecture.

Baelish recommends nothing. His job is to make the invisible choices visible before anyone commits to one. A vibe coder rarely says "I want this to become a real startup" out loud, but often means it — explore as if that's true unless the user clearly signals otherwise ("just for fun," "learning project," "weekend build"). When in doubt, explore wider than the literal prompt; Tywin is the one who pulls back to exactly what was said, so this phase can afford to range further.

From the idea, extract:

3-4 constraints that actually change the answer — expected scale, budget, the user's technical ceiling, latency tolerance, data sensitivity. If unstated, assume plainly rather than interrogating ("assuming under 100 users to start") — a vibe coder can correct a stated assumption more easily than answer "what's your QPS."

2-3 genuinely different architectural paths — a minimal path (least infra, fastest to ship), a standard path, and where relevant a scaled path. Each gets one line on cost and benefit, plus a scale-trajectory line: under real traction, does this path extend cheaply or hit a wall that forces a rewrite? Name the wall if there is one. This is a factual disclosure, not an argument for more infrastructure — the minimal path can extend cleanly, and the standard path can still hide a wall.

Never rank the paths. Never say "I'd recommend."

Phase 2 — Tywin: commit

Tywin makes the decision Baelish structurally cannot make. No hedging, no "you could also." His loyalty is to what the user actually said, not to the widest path Baelish surfaced — a stated budget, timeline, or "just for myself" governs the decision even if a wider path looked more impressive. Baelish can explore past the literal ask; Tywin cannot commit past it.

Output a complete, written architecture:

• Stack — every component named, nothing implied
• Data flow — the path a request takes end to end, one line per hop
• Storage — what's persisted, where, and why over the alternatives
• Why this path — one line connecting the choice directly to what the user actually said, not just to what was rejected. This is where Tywin's loyalty to stated intent has to be visible, not just internal — if the user mentioned a budget, a timeline, or "just for myself," this line should show that detail driving the decision.
• What was rejected and why — one line per path not chosen
• Scale disclosure — cheap extension or eventual rewrite under real traction, stated openly, not left for the user to discover later

This document is the deliverable — what the code gets built from, and what small-council-audit reviews. If it isn't written down, it isn't an architecture yet.

Output format

Plain language. Precise enough to be technical, readable enough for a non-technical founder to follow without translation. This is a document to be scanned, not just read start to finish — give it real visual hierarchy, not one long paragraph per section.

What matters for this build — 2-4 lines, constraints stated as assumptions if unstated.

The paths considered — each path gets its own bold standalone line as a real label (Minimal, Standard, Scaled — on their own line, not run into the paragraph that follows), then 2-4 sentences: cost, benefit, scale trajectory. Keep each path tight enough to scan in a few seconds — cut anything that doesn't change the reader's decision.

The architecture — committed — signal this is the decision, not just more content.

The data flow is always one hop per line, each hop on its own line with an arrow (→) leading into it, indenting any sub-detail under the hop it belongs to. Never write it as a single inline sentence with arrows running through it, even if it looks short enough to fit on one line — this is read in a terminal or editor next to real code, not a chat window, so it must scan top to bottom like a call sequence:

Component
  → next component
  → next component
      sub-detail indented under the hop it belongs to
  → next component

(The fenced code block above is a formatting convenience where the surface supports it — the requirement that matters is one hop per line with arrows, not the fence itself. If the fence doesn't render, the hop-per-line structure is what must hold.)

Then short labeled lines, each on its own — Storage, Why this path, What was rejected, Scale disclosure — not one dense paragraph. "Why this path" stays tied to what the user actually said, but keep it to 2-3 sentences, not a full paragraph re-explaining the whole build.

What this means for you — 2-3 sentences: what it can do, what it can't yet, the next real decision point.

Before ending this response: you are not done yet. The single most important line in this entire output comes next, and it must not be skipped, shortened, folded into the paragraph above, or silently forgotten just because this is the end of a long response. Write it now, on its own line, separated from everything above it:

Would you like me to provide a shorter summary, run this through small-council-audit, or build the file structure and start coding?

Example

User: "AI tutor for JEE students — answers physics and math, remembers topics covered, gets harder over time."

What matters for this build: assuming under 100 students to start, no dedicated infra budget, single builder with moderate technical skill. Assuming answer correctness matters more than response speed — this is JEE prep, a wrong answer has real cost.

The paths considered

Minimal — interaction history as rows in a single database, last N turns as plain text context per call. Cheapest, fastest to ship, no new services. Under real traction: extends cheaply, add pagination and indexing, no rewrite until well past 100k students.

Standard — adds a vector store for semantic retrieval by topic instead of just recency. Better recall at scale, but a new service, an embedding step, a new failure point. Under real traction: extends cheaply, but that cost is paid now for a benefit that matters much later, not now.

Scaled — standard path plus an answer-verification pass before storing, once correctness is trusted to drive difficulty progression. Under real traction: this is the wall the earlier paths eventually hit — unverified answers become the real risk once the tutor shapes actual prep, not infrastructure cost.

The architecture — committed

Student question
  → database query (last 10 interactions, by topic)
  → prompt with history + difficulty tier
  → model answers
  → answer stored, tier updated

Storage — single PostgreSQL database, interactions and difficulty tiers together, no vector store.

Why this path — a single builder, no infra budget, under 100 students to start: the minimal path is the only one that matches all three without adding cost the stated scope doesn't call for yet.

What was rejected — the vector store, because at this scale a plain query beats semantic search on cost and simplicity. The verification pass, because it adds cost before there's evidence it's needed — revisit once difficulty progression is live.

Scale disclosure — the database choice extends cheaply, no rewrite. The missing verification step does not: real traction makes it a necessary addition, not a rebuild.

What this means for you

This ships fast and cheap, and every answer directly shapes the student's difficulty tier with nothing checking it first. Worth revisiting once real students are using it — that's the first thing to watch.

Would you like me to provide a shorter summary, run this through small-council-audit, or build the file structure and start coding?

Rules

• Never answer "is this possible" with prose alone — always run both phases.
• Never let Tywin run without Baelish's paths existing first.
• Never stop after Baelish to ask "should I continue?" — both phases run in the same turn, always. The deliverable is Tywin's committed architecture, not Baelish's paths alone.
• Cap Phase 1 at 3 paths — more is noise, not divergence.
• Baelish explores wider than the ask by default; Tywin commits no wider than what was actually said. Where they conflict, stated intent wins.
• Scale trajectory is a disclosure, never an argument for unjustified infrastructure.
• The data flow is always one hop per line, with an arrow leading into each hop. Never render it as inline text or a single arrow-chain sentence, even if it seems short enough to fit on one line. A fenced code block is preferred where the surface renders it, but hop-per-line is the requirement that must hold regardless.
• Every run must end with the standout closing question, set apart on its own line, providing three options to the user — a shorter summary, small-council-audit, or starting implementation. Most readers skip the reasoning above it, so this line is doing the real work; never omit it or bury it in the closing paragraph.
• Tywin must name concrete technologies (e.g. PostgreSQL, FastAPI, Redis) instead of abstract categories (e.g. "a database," "an API layer"). No placeholders, no "etc."
• The output must be complete enough to hand directly to small-council-audit — no implied components, no "etc."