Console.

Every Signalform client gets a daily-driver console.

When you spin up a new client at Signalform Studio, you don't start from zero. You start from FSI — the Frontier Security Institute build that we treat as the reference implementation for a whole class of deliverable we call the console. It's not just a website. It's a tab the client keeps open all day: a calm operator's terminal that holds every brand asset, every tool, every open decision, and a small map of where the engagement actually is.

The pitch is simple: a brand isn't a logo PDF dropped into a Dropbox folder, and a website isn't a deliverable that gets handed off and forgotten. They're operating surfaces. The console is the place those surfaces converge — designed to feel personal enough that the client wants to live in it, and rigorous enough that we can ship updates to it for months without rebuilding the foundation each time.

This guide is for the next person — Mike, a contractor, or any client trying to understand what they just bought. It explains what a console is, why FSI is the canonical example, what we learned from building it five times in five passes, and what's now portable so the next client doesn't get the slow version.

What FSI taught us, in five passes.

The Frontier Security Institute console started as a single HTML file with a sidebar, a few cards, and a feature-request form. It looked competent. It also failed in exactly the ways that all "brand portals" fail: it was a directory of stuff, not a place anybody wanted to be. So we rebuilt it. Five times.

Pass one — Launchpad.

We threw out the dense "pinned" grid and replaced it with six icon-led tool tiles. The hero split horizontally: a greeting on the left, a live agenda of open items on the right. The type scale doubled. A Cmd-K command palette appeared in the top bar, ready to ferry the user anywhere with three keystrokes. The console started to feel like a console.

Pass two — Hardening.

Adversarial reviewers found seven things wrong. Two were embarrassing: the body font was system-default instead of the brand serif, and status pills failed WCAG contrast against the navy hero panel. We wired up Seasonsans, Seasonmix, and Jjannon from the parent system. We added focus-visible rings to every interactive surface. We refactored the tool list into a single CATALOG data structure that renders the dock, the sidebar nav, and the Cmd-K index from one source.

Pass three — Desktop mode.

Susan asked for a "clean open space." We built a focus surface that strips every piece of chrome — sidebar, topbar, pages, downloads — and leaves just the cover photo as canvas. Six large glass tiles for tools. A glass clock + greeting widget top-left. A collapsed agenda pill top-right. Cmd-K still works. Esc gets you out. Press D to toggle.

Pass four — Polish.

Three more reviewers. The agenda widget had invalid nested-button HTML. The vignette on busy event photos let tile labels lose contrast. The "Talk to Mike" floating button pulsed cyan against a calm canvas in a way that screamed startup. We fixed all three. The reduced-motion preference now suppresses the tile-stagger animation. The clock interval clears when you leave desktop mode.

Pass five — Template.

And then we asked the question Mike had been chewing on: what would it take to do this for every client, on day one of the engagement, without rebuilding from FSI by hand?

Not every engagement gets the full console.

The template ships modular. The intake conversation — the first hour with a new client — picks one of three engagement shapes. The shape decides which directories materialize. A small brand-identity job doesn't need a Cmd-K palette. A full operating-system build does. The point is that the template can serve all three from one source.

What the shape doesn't decide is the design quality. The S-shape brand kit gets the same care as the L-shape console. The difference is whether the client wakes up in the morning and opens it.

One config file, three render functions.

The biggest move in the template isn't visual. It's that every tool list in FSI used to live in three places at once — the dock on the home panel, the sidebar nav, and the Cmd-K palette index. Renaming a tool meant editing three files and hoping you didn't miss one. That's the kind of drift that kills a deliverable in month four.

So we collapsed it. The template now reads from a single CATALOG data structure. Three render functions take that data and produce the three views. Adding a tool is one entry; the dock, the sidebar, and the palette all pick it up.

The same principle runs across the whole template. Brand colors, fonts, the client name, the operator's email — every FSI-specific value has been pulled out into a client.config.yaml file. The intake conversation fills it in. A future Claude skill called /sf-new-client will read it and substitute the placeholders into a fresh client repo on demand.

identity:
  legal_name: "Frontier Security Institute"
  initialism: "FSI"
  slug: "frontier-security-institute"
  affiliate: "at the Center for AI Safety"
  engagement_shape: "L"   # S | M | L
  register: "calm authority"

brand:
  primary_hex: "#1c1d5f"
  accent_hex: "#00adff"

typography:
  display: { family: "Seasonmix", fallback: "Times, Georgia, serif" }
  body:    { family: "Seasonsans", fallback: "-apple-system, sans-serif" }

people:
  - name: "Susan Malandrino"
    title: "Vice President for Communications"
    email: "smalandrino@frontsec.org"
    is_console_user: true

The config drives 60-plus placeholders across the template skeleton. {{TEMPLATE_PRIMARY_HEX}} in the CSS. {{TEMPLATE_CLIENT_NAME}} in every page title. {{TEMPLATE_USER_FIRST}} in the desktop greeting. Each value substituted at materialization time. Nothing magic — just one source, many readers.

What's portable, what's not.

Portable: the hub layout, the Cmd-K palette, desktop mode, the card maker, the cover-photo system, the deploy pipeline (GitHub Actions → Cloudflare Pages), the snapshot/rollback pattern.

Not portable: actual logo files, headshots, cover photos, custom illustration, copy. Those are per-client, always — and they're where the design hours actually go.

Five calls that shape the template's future.

The skeleton is built. The blueprint is written. The skill that consumes the config and produces a client-ready repo is the next thing. Before we build it, five decisions sit on the table:

Forecast for the rest of the system.

The template skeleton lives at the Signalform Studio blueprints directory. The blueprint document covers engagement shapes, intake conversation, config schema, the parameterization surface, and the open decisions. The next move is the /sf-new-client Claude skill — about four to six focused hours of work to ship a working intake + substitution layer. After that comes the first dry-run on a non-FSI client, where we find out what's actually painful.

Further out: a Signalform-Studio-wide console of its own — a meta-hub listing every active client engagement, their deploy status, last activity, open agenda items. The studio's own dogfood version of the thing we build for everyone else. Eat your own console.

The point of all this isn't that we built a nice-looking hub for one client. It's that we know how to build the same kind of thing again — faster, with more weight on the parts that actually matter to the engagement (custom copy, real photography, the brand decisions that take taste and time) — because the surface underneath has been parameterized.

The console is the canvas. The template is the press it gets printed on. The work, still and always, is making each one feel singular.