How can we help?

Lyra is Speero’s Experimentation Operating System. Each client engagement is a Program. A program holds registers: Research, Experiments, Ideas, Delivery, and Assets, with Observations living inside each experiment.

Registers are fixed by design. The flexibility lives in custom fields, sub-stages, saved filters, and automations. If a process seems to need a new register, it usually needs a saved filter or an automation instead.

Go to the app and continue with Google. Access is restricted to speero.com accounts.

There is nothing to configure: the first sign-in creates your account, and any program invitations waiting on your email activate at that moment.

Signing in lands on the home page: a greeting, the portfolio pulse (programs, live tests, experiments), and a jump card per program that links straight into its experiments, research, and dashboards.

The full portfolio list with program creation lives at Programs. New program opens a dialog: name, client code (baked into every Test ID, so choose it well), an optional description, and the icon and color that identify the program everywhere. The creator becomes the program’s first admin.

The workspace is the program’s home. The register tabs run across the top, Research far left, then Experiments. The header carries the Dashboards button (the stakeholder-facing surfaces, open to every member) and the management actions: Manage members, Settings, and Automations.

The layout switcher on the experiments register picks how you see it: Board (kanban by stage, full page width), Grid (the working table), Gallery (rich cards), or Timeline (grouped by month with run windows).

The filter bar is its own control and feeds every layout the same way: search, stage, parking, approval, and impact type.

A saved filter keeps a layout, a set of filters, and for grids the sort and columns. When the view on screen diverges from the saved filter, Save this filter appears beside the filters; a default filter never changes, so there it saves as a new one.

A new saved filter is yours alone unless you share it with the program, and the picker separates shared filters from your own. The board drops the backlog and complete columns unless the filter says otherwise, and any column collapses to a strip. Bulk actions (move, approval, block, pause) run through the same gates as single edits.

Click any row or card. The header reads code, test name, touchpoint. The status note sits right below it: one plain field for where the test stands right now, free to edit any time. When the stage changes, the note archives into the journey and clears, so the note is always current and the history keeps what it said.

The tabs cover framing, classification (variables, never free-text tags), PXL and lifecycle, results, observations, comments, and the Journey: the test’s whole story as a timeline, stage moves with time-in-stage, observations, and audited edits, with the field-level version list folded underneath.

Every save is versioned: if someone else saved while you were editing, Lyra tells you and reloads the latest instead of silently overwriting either of you.

Every experiment moves through the fixed stages: idea, backlog, prep, design, dev, qa, ready, live, analysis, complete. The idea stage is the pre-experiment funnel; the pipeline runs backlog through complete.

Blocked and paused are parking flags, not stages: they mark a test held in place without losing where it stands.

Gates sit between stages and hold a test to standard before it can advance. The flagship is pre-registration: hypothesis, primary metric, and success criteria lock before a test goes live.

Pre-registration exists for one reason: to prevent results from being interpreted retroactively. Decisions made after seeing data are not decisions, which is why the win, flat, and loss actions are written down before launch and why changing them after unblinding is a protocol violation, not an edit.

When a gate blocks a move it names the missing fields. Fill them on the test, then move it again; nothing else is required.

After the gate passes, editing a pre-registered field requires a note and lands in the audit log, so the original claim is always recoverable.

Programs can add custom gates on top of the standard ones in Settings. A custom gate never takes effect on save: it lands as pending and starts enforcing only when an admin or owner approves it. Custom gates extend the standard ones, never weaken them.

A test runs its planned runtime. Extending runtime to chase significance inflates the false positive rate, and stopping early is justified only when a guardrail metric critically breaches. Single-send campaigns stop on sample size instead of days.

Flat means the point estimate sits inside the symmetric band around zero bounded by the pre-committed MDE. Flat is not the same as statistically insignificant, and a flat result triggers the pre-committed flat action like any other.

A sample ratio mismatch means stop and investigate before analysing anything. Never treat SRM as normal variation.

Pause a live test only for a real reason (an SRM, a pipeline failure, a major incident) with a note, and expect the runtime clock to restart when it relaunches.

Test is the unit of experimentation; experiment is the same thing in API names. The versions compared are the control and its variants, sharing a traffic split, with an optional hold-out kept out of the exposed cohort entirely.

The success definition is the explicit win, flat, and loss thresholds. Pre-commitment is the action declared for each of those outcomes before launch. The recommendation after a test is implement, iterate, abandon, or more evidence.

The takeaway is the per-test conclusion; a learning is the minted, atomic statement in the learnings register with its sources attached. Moving a test backward one stage is a walk back, always with a note, always audited.

Sub-stages are client-facing labels inside the fixed lifecycle. Each label belongs to exactly one stage, and the first label of a stage is where a test lands when it enters that stage.

Gates, dashboards, the digest, and metrics read stages only, so sub-stages never fork governance. The kit is edited in Settings: renaming a label rewrites every test carrying it as an audited change, and removing one clears or reassigns within the stage.

Problem, hypothesis, success criteria, and the PXL inputs lock the moment they first hold a value. Filling an empty field is free. Changing a value that was already set requires a note explaining why, and the change is audited into the journey.

The canonical PXL3 score builds from structured inputs to a 1 through 10 score: the swimlane tier of the linked touchpoint, effort, data strength, and an iteration boost when the test iterates on a previous one.

Missing inputs mean no score, never zero. Legacy scores imported from older dialects stay static and flagged non-comparable.

Ideas are the pre-experiment funnel with the same PXL scoring as experiments. An idea lives at the idea stage with no Test ID.

An idea that gets implemented directly without a test is marked JDI (just do it) with its date. A dismissed idea stays on the record without ever drawing a number.

Promoting moves an idea through the promotion gate into the backlog, where it draws its Test ID. The gate requires the problem framing and a PXL score, so nothing unscored enters the pipeline.

A blocked promotion tells you exactly which fields the gate still needs. The promotion itself shows in the experiment’s stage history: the record is the same, only the stage moved.

Each program has a shareable intake link that outsiders can use to submit ideas without a seat. It is the one public surface: write-only, rate-limited, and a dead link says so instead of looping.

The link is managed from the program workspace, and regenerating it invalidates every previously shared copy.

The research register tracks research projects with their own stable Research IDs (like PR-R12), goals, questions, methods, and results. Research links to the delivery items and periods it belongs to.

Delivery is the receipts: each item links the experiments and research it covers, scoped as standard, free add-on, or upsell. The SOW lives on the same register as one monthly number (tests, and research when the SOW tracks it) that every month inherits, and each period shows delivered counts against it.

Observations are the live-test peek log, living inside each experiment: dated notes with a type (day-after verification, ongoing, final) and a recommendation on whether to keep going.

Dashboards are read-only curated pages, the same seven for every program: overview, pipeline summary, results gallery, delivery vs SOW, learnings library, trends, and the QBR page.

The structure is deliberately identical across programs, so the team and clients never relearn a layout. The pipeline summary shows pipeline value: the summed revenue estimates of every test still in flight.

The QBR page reads the strategy chain: the goal tree from north star to problem statement, with the quarter’s launched, completed, and win counts rolling up every level. Its Export button ships a print-ready document.

The test doc on an experiment’s results tab is the shareable per-test artifact: framing, run dates, per-arm results with the stats, takeaway, and recommendation, generated from register data so it is always consistent with the system of record.

The Decks button in the program header opens concept decks: client-ready presentations of a chosen set of ideas and backlog experiments. Every fact on a slide (title, problem, hypothesis, goal, PXL) renders live from the register, so a deck can never drift from the record it presents.

Build a deck from the concept picker, add a screenshot per slide and drag highlight boxes over it, write a presenter note, then Present for a full-screen run-through or Print for a PDF. A share link gives a client a read-only view with no account.

When the client approves a concept, Approve into pipeline promotes its idea through the real idea gate, drawing the Test ID when the gate passes, so an approved concept becomes a backlog experiment in one step. A concept that still needs a problem or PXL score is held at the gate with a plain note of what it needs. A concept already in the pipeline shows its Test ID and stage instead.

The Variables tab, at the end of the register row in the program workspace. The goal tree leads: one chain from the north star through objectives and strategic pillars down to problem statements. Each node carries a long-form detail (what it means for the client, the evidence, what winning looks like).

An experiment links to one goal from the framing tab, ideally the most specific node, a problem statement if one exists. Tests run and revenue roll up the chain recursively, and the QBR and overview dashboards read the whole tree.

Touchpoints carry the URL they live at and the swimlane tier that feeds PXL. Audiences, themes, metrics, and markets manage inline.

Nothing here is free-text tagging: experiments classify against these variables so every rollup stays trustworthy.

Settings, then Automations. The deterministic set: the pipeline digest, Slack notifications on stage transitions, stale-test flags, and the scorecard render on completion.

An automation is a trigger plus an action, and none of them are AI. They run regardless of the account’s AI toggle.

Owner is account-level: full control of everything in Lyra, every program included. It is granted and revoked in the admin area, never on a program roster, and Lyra always keeps at least one owner.

Program rosters hold four roles, one per person per program:

• Admin — the Speero lead on the program. Program settings and sharing, plus everything a manager can.
• Manager — the day-to-day operator. Creates and edits records, moves tests through the lifecycle, edits client configuration.
• Editor — client seat. Will edit curated surfaces when the client portal ships. Cannot sign in yet.
• Commenter — client seat. Will comment on curated surfaces when the portal ships. Cannot sign in yet.

Members page, add by email. Someone with a Lyra account is added immediately. Someone who has never signed in is invited, and the invitation turns into their membership automatically on first sign-in.

Rank rules apply everywhere: you can only grant roles below your own, and owner is never grantable on a roster.

From the admin People tab: suspending a person blocks sign-in and ends their sessions immediately while keeping their roster and history. Removing them from Lyra ends sign-in, memberships, and their personal tokens at once.

Personal tokens (under the user menu) act as you: pick a name, the program, the scopes, and an expiry. A token’s real power is recomputed on every request as the intersection of its scopes with your live access, so losing access to a program instantly narrows every token you hold.

The full token is shown once at mint and never again.

Service keys (admin area, Developer tab) are standing credentials for unattended systems. Only an owner mints them, scoped to one program or to all current and future programs. Program admins see every key that reaches their program.

A whole program runs from the shell: setup, variables, gates, automations, experiments through the lifecycle, members, backups, and the QBR rollup are all commands.

Install with: pnpm add -g "github:Speero-AI/lyra#path:cli", then lyra login. The full command reference is generated from the CLI itself so it never drifts.

Everything the UI does the API does: /api/v1 with a bearer token, and the MCP server exposes the same operations to agent tooling.

Writes made with a token record the token’s name in the audit trail and version history, so provenance survives automation.

Settings shows sections by what your role reaches. Client configuration (name, client code, slug, SOW renewal, digest channel, register visibility, identity) is manager and up.

Changing the client code re-labels every Test ID and warns before it does.

The SOW is set once on the Delivery register: tests per month, and research per month when the SOW tracks it. Every month inherits those numbers, a single month can be edited away from them, and delivered counts come from the delivery receipts that link tests and research.

Editing the SOW is manager and up. The SOW renewal date lives in client configuration.

Backups run nightly and on demand, and the archive contains every register plus attachments. Restore is non-destructive: it writes through the same versioned paths as any other edit, so history stays intact and the restore itself is audited.

Automatic restore covers the fields of experiments, ideas, research, and assets, and deleted experiments and research come back under their original IDs. Variable links, external links, comments, attachments, lenses, and automations are not restored automatically; the archive keeps all of them for manual recovery. Cloud SQL point-in-time recovery remains the primary full-system recovery path.

Every restore is recorded as a run with per-register progress. A run that fails partway shows up as failed with its error, and resuming it picks up exactly where it stopped without touching rows it already restored.

Lyra is AI-optional: no core workflow depends on a teammate, and any program can switch them off. It is on by default for a new program, so the toggle is how you turn it off. Changing it takes an owner or an admin. The deterministic automations are not AI and run regardless.

The last section of settings holds the three actions that reshape or remove a whole program. All three are owner only, and each asks you to type the client code before it will run.

Duplicate builds a second program from this one. Structure only gives you the empty shell (settings, members, gates, sub-stages, variables, lenses, SOW budgets, and the goal tree) with numbering starting at 1. An exact copy brings every record too. Copied automations arrive switched off, and API tokens, webhooks, share links, the digest channel, and file attachments are never copied.

Strip all records empties the registers: every test, observation, research entry, delivery, learning, asset, deck, comment, attachment, and version, with numbering restarting at 1. Everything that makes the program itself stays, and backup archives are kept, so a restore can bring register data back.

Delete removes the program from every list, address, and API at once, switches its automations off, and revokes its API tokens. It is not gone yet: an owner can restore it whole from Admin, Programs for 30 days, though automations stay off and tokens stay revoked after a restore. The program keeps its name, client code, and address reserved for that window. Delete forever, on the same admin card, ends the window early and frees all three for immediate reuse, and nothing can be recovered after it.

The admin area is visible only to owners, with three tabs.

• Programs — every program in the portfolio with member counts and status, and buttons into each program, its members, and its settings.
• People — everyone who can sign in, with search and filters. Manage roles in place, add or remove programs, suspend, or remove from Lyra. Owner grants live at the bottom.
• Developer — mint service keys, see the portfolio-wide token inventory with emergency revoke, and manage encrypted secrets for intelligence providers.

Lyra is built to be usable by keyboard and screen reader end to end.

• The first tab stop on every signed-in page jumps past the chrome to the content.
• Register rows and cards open with Enter or Space, the board moves cards with Space and arrows, and Cmd or Ctrl+Enter saves the editing tabs.
• Every animation respects prefers-reduced-motion, landing on its end state instantly.
• Body and secondary text meet WCAG AA in both themes, and focus rings are visible on every surface.
• Found a gap? File it like a bug. Accessibility regressions are defects, not polish.

The intake link is the one public surface: anyone with the link can submit an idea, no account needed.

Client seats (editor, commenter) can be granted now so rosters are ready, but they have no sign-in until the client portal ships. When it does, client seats will see curated dashboards and external comments only, never internal notes, raw registers, or member emails.