How can we help?

Lyra is Speero’s Experimentation Operating System. Each client engagement is a Program. A program holds four registers: Research, Experiments, Delivery, and Assets. Ideas are tests at the idea stage inside Experiments, and Observations live inside each test.

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 Portfolio: one list of the programs you can reach. Each row names the program and your role, then only what asks for attention: how many things are waiting on you, live tests, blocked tests, research in flight, and agent runs in the last seven days. Star a program to keep it at the top of the list. Search and sort sit above it, and when you can see more programs than you are assigned to, My programs and All switch between the two.

Owners and admins also see New program. It opens a dialog: name, client code (baked into every Test ID, so choose it well), an optional description, and then the icon and color that identify the program everywhere. The creator is assigned to the new program.

The Library, on the platform rail after the Portfolio, holds what is reusable across programs. Owners and Lyra admins see it.

Insights is the delivery check across every program you own and a search of learnings and tests across them. Global variables are the values every program classifies against in common. Research methods says what a study usually takes by method and tool, and a Lyra admin sets those figures. Recipes lists the research recipes Lyra ships. A recipe is started from a program’s Research register or goal tree.

Opening a program lands on its Home. The rail on the left holds the program, top to bottom the way the work runs: Home, Strategy, Research, Experiments, Delivery, Learnings, Reports, and Client, with Settings at the foot. Strategy frames the work, research explores, experiments validate, delivery ships, learnings close the loop, and reports say how it is going. A register the program hides leaves the rail.

Three things say which program you are in. The top of the rail shows its tile, name, and client code, and clicking it switches programs. The breadcrumb on every page reads Portfolio, then the program, then where you are, and its program name switches programs too, keeping your place. A thin line across the top of the page, and the rail’s top block, wear the program’s own color. Outside a program the rail says Speero · Portfolio and carries no program color.

Each part of the product carries its own hue, on icons and dots: violet for research, sky blue for experiments, orange for delivery, lime for assets, magenta for strategy, and teal for agents. A hue says what something is, never what state it is in.

Home leads with a rollup of the standing numbers: tests live, tests blocked, tests awaiting sign-off, what the learning loop still owes, and agent errors when there are any. Each number links to the place you act on it.

Below it is one list of what moved in the last seven days: how many tests changed stage, went live, concluded, and passed a gate, then the latest moves by name with a stage chip each. Five show, and the rest wait behind Show more.

Agents, older drafts, and reports are one line each, with the detail behind a click: recent agent runs and errors, drafts written before drafts were retired (oldest first), and each report or view with who looked last and how often. Home only reads. Nothing on it changes the program.

Ask Lyra in the program header opens Lyra in a panel on the right, from any page in the program. Ask about the program and Lyra answers from its registers, naming tests by ID and saying so when something is not there.

Describe a change to try and Lyra adds it as a test idea: a normal row at the idea stage, carrying only the problem, hypothesis, and evidence you actually stated, and showing that Lyra wrote it. Undo sits right in the thread. Lyra never promotes an idea, and a QBR, a learning card, or a research brief is another agent’s job, so Lyra names which one.

Closing the panel or moving between pages keeps the thread while you stay in the program. Ask Lyra shows for seats that can write, and only when AI is on for the program.

Experiments has one control row: search, the saved filter picker, the layout icons, Filters, and a menu for the rest, with New experiment on the right. The layouts are Board (kanban by stage, full page width), Grid (the dense, spreadsheet-style layout), Gallery (rich cards), Timeline (grouped by month with run windows), and Gantt (tests per swimlane over time, each bar a run window).

After the layouts sit Experiments’ other views, each a page of its own and also under Experiments in the rail: the pipeline viewer (a filterable test list beside the whole test), review by gate (tests waiting at their next gate with what each is missing, and one-click approve and advance), and the results gallery.

Filters opens one panel with stage, parking, approval, and impact type, and feeds every layout the same way. A count on the button says how many are applied. Above the tests, a rollup line gives the count and what needs attention, and every layout but the board adds a chip per stage with its count. Each count and chip is a filter: click to narrow, click again to clear.

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 on the control row. A default filter never changes, so there it saves as a new one. On the grid, save from the Save button beside Columns.

A new saved filter is yours alone unless you share it with the program. The picker lists Ideas first, then the default filters, the shared ones, and your own. The board shows in-flight stages only until you pick Show backlog and complete columns from the row’s menu, and any column collapses to a strip. Bulk actions (move, approval, block, pause, archive) run through the same gates as single edits.

Click any row or card to open the test in a slideout. The header reads Test ID, test name, and touchpoint, with the stage, approval, and any parking flag beneath, and Comments and Review buttons that carry a dot when something is waiting. The status note sits below: 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 are Overview, Framing, Classification (variables, never free-text tags), Lifecycle (with PXL), Results, Comments, and 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. Overview only reads. It opens on one lead block (the next gate, days live and the stopping rule, or the outcome), its sections fold to a line each with the stage deciding which start open, and each section’s Edit pencil jumps to the tab its fields live on.

Open as a page, the icon at the top of the slideout, gives the test its own address. The page opens on the same summary, and its tabs sit in one folded block, All fields and editing, closed by default and remembered per person. An Edit pencil, the Comments button, or ?tab= in the address opens it for that visit.

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.

Callsheet shows a program’s tests from the client’s own Airtable base, for everyone at Speero, read only. It is for programs whose tests still live in Airtable. Edit in Airtable as always. Callsheet refreshes from Airtable when someone opens it, at most every five minutes, so a change shows on your next page load, and opening a test refreshes that test at once. Callsheet never writes to Airtable.

A program with Callsheet on has a Callsheet item in its rail, after Experiments. Its first page is one tile per status with the number of tests in it. Click a tile to show only that status in the list on the left, click it again to show all. The filter rides in the address, so a link you share opens on the same filter.

The list on the left holds every test in flight, grouped by status in the order the work runs, with blocked, paused and live at the end. Drag its edge to make it wider or narrower, and it keeps that width.

A test’s page starts with its ID, status, name, documents and links, and the status note. The copy icon beside the status puts a status update on your clipboard, ready to paste into Slack: the status, ID and name with touchpoint, the links, and the note. Below the header, Overview, Design, Dev and QA follow in one page, because every part matters to every role. The bar above them jumps between sections.

In Design, Treatment holds what the variant should look like, marked Approved or Not approved yet when the base keeps that flag, and References holds what the design team works from. Control and variant can be compared side by side or with a slider.

A test that leaves the pipeline, done or stopped, shows its final status only. When a program moves fully into Lyra, its Callsheet is switched off and every Callsheet link forwards to the same test in Lyra.

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, and 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.

A few more checkpoints sit further along the same ladder. Moving into prep asks for a goal: nothing runs without a reason, so the test links the goal it works against, ideally the problem statement it attacks. Moving into dev asks for a design artifact (a design link, a prototype link, or a variant screenshot). Moving into ready asks for measurement notes (how the read will be taken), the win, loss, and flat actions, and the planned runtime, so the test reaches its approval with every pre-commitment written down. Choosing a kind for an action is enough, unless the kind is something else, which needs the action written out. Going live also asks for a primary metric that can decide the test, not one marked report-only, and for a non-inferiority test, the margin it will be judged against. Moving into analysis also asks for the stopping rule pre-registered for this run.

Every test has a type. Superiority, the default, asks whether the variant beats the control. Non-inferiority asks whether it is no worse than the control by more than a margin you set before launch. The type and the margin are pre-registered with the pre-commitments and lock with them once the test is approved.

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

A gate checks a test when it moves into that stage. A test already past a stage keeps its place when the standard for that stage rises, and meets the new standard the next time it moves into it.

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 analyzing 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, and 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 is a test at the idea stage, with no Test ID yet. Pick Ideas at the top of the saved filter picker on Experiments to see them, and New idea sits in the create button’s menu on every view.

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, so nothing unframed enters the pipeline. A PXL score is optional.

The gate also requires the scoping inputs to have been read: written by a person, or written by an agent and confirmed by one. An assertion an agent wrote and nobody has read blocks promotion until someone confirms it.

A blocked promotion tells you exactly which fields the gate still needs. The promotion itself shows in the experiment’s stage history: only the stage moved, nothing underneath it changed.

Before a test spends a slot, the Intake scoping block on its Lifecycle tab checks seven signals that a question belongs in research first: thin grounding (nothing learned or studied on its problem statement), no mechanism (no theme and no belief), competing directions (open tests on the same problem with different themes), stalled tests (the last two on the problem ended flat or in error), an unreadable surface (every linked scenario is T3), expensive or irreversible (high effort), and a contradicted belief.

Each signal that fires says why. One is a flag to read before the test runs. Two or more means research first, and the block offers Draft the study, which writes a study from the test with the signals as its reason. Nothing here blocks a test.

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.

Managers and up share the link from the Ideas view on Experiments. 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.

The list groups studies by status: the work that is moving first, then what is queued, then what ended. The ended groups start folded, one click away.

A test can cite any number of studies, and a study can feed any number of tests. Add or remove the studies a test cites under its name on the test page, and a study lists the tests it feeds.

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. They read in the test’s Journey, and they are logged through the API, MCP, or the CLI.

A result is one row per variant, metric and period on the Results tab: visitors, conversions, lift, significance and the confidence interval, each saved on its own. Percents are percents, so significance is 95, never 0.95. Saving the same variant, metric and period again updates that row.

The test page, the test doc, the scorecard and the QBR all read the same headline: the whole reading on the primary metric, from the first variant with a lift or significance. Lift and significance typed before results moved to these rows stay visible as reported, read-only. Outcome and recommendation stay a person’s call.

A non-inferiority test is judged against its margin through the confidence interval on that headline. Non-inferior when the low end stays above minus the margin, inferior when the high end sits below it, inconclusive while the interval crosses it. Without the interval the call waits. A superiority test reads as it always has.

Reports, in the program rail, says how the program is doing, with the same set for every program: the program overview, delivery vs SOW, velocity and win-rate trends, and the QBR. Each reads only. The structure is deliberately identical across programs, so the team and clients never relearn a layout.

New dashboard, at the top of Reports, builds one the program owns outright, listed below the shared set. A shipped dashboard, the old pipeline summary included, can be its starting point.

The views that work on tests live in Experiments: the pipeline viewer, review by gate, and the results gallery. The pipeline summary became the stage chips on the Experiments register.

Learnings, in the program rail, says what the program knows: every learning and takeaway, filterable by goal and by source, with the learning loop’s health above them.

The loop queue at the top lists the concluded tests and complete studies the learning loop has not read yet. The loop marks what it reads itself, so the queue shrinks as it works.

Some clients keep their tests and research in a system Speero can read but not change, such as an Airtable base shared as a read-only view. Such a program names that system under Settings, General, in Where the work lives, and Research, Experiments and Home then say where its work is instead of showing an empty register.

The learning loop still reads that work and keeps what it learns in Lyra: the learnings, the beliefs and the goal tree. For each outside test or study it reads it keeps one line with the name, the link and the result as the client recorded it. Learnings lists them under Outside tests and studies, filterable by kind and by whether the loop has written them up, and a learning names each one it rests on as, say, Test in Airtable, linking out.

Lyra never writes to the outside system. The outcome and dates on each line are a copy from the loop’s last read, so they are only as fresh as that read.

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.

Strategy sits in the program rail, ahead of the registers, because it frames the work and every register row points at it. A line at the top names what needs a look and jumps to it. 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).

Every section on the page, the goal tree, touchpoints, metrics, drivers, beliefs, scenarios and the rest, folds to a one-line rollup, and this browser remembers which you left open.

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, and markets manage inline. Metrics have their own catalog, and changing what a metric counts goes through a Definition proposal that an owner, admin, or manager signs off.

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

A metric driver says one metric moves another, and a mechanism belief says a theme moves a metric. Support, assumed, correlated or demonstrated, is worked out from the evidence and the learnings that bear on the belief. Nobody types it.

Agents gather and attach, people grade, retire and decide. An agent, whether the Claude connector, the CLI or an API token, can draw a belief, attach evidence and write learnings. Refuting, retiring or reactivating a belief, removing evidence and marking a grade reviewed happen only from your own session in Lyra.

A learning an agent wrote shows on the beliefs it bears on as pending a person’s check. It moves no grade and owes no re-grade until someone confirms the learning, from the belief’s learnings list or from Learnings. Evidence an agent attached counts up to correlated on its own. To count as demonstrated, a person reviews the grade.

Re-grade owed means a learning that contradicts the belief, or a precise null, landed after a person last reviewed the grade. Refute it, retire it, or keep it and press Mark reviewed. Editing the belief does not clear it, and nothing an agent does clears it.

Settings, then Automations. New automation opens the same panel used to edit one, empty, so you pick a trigger and the action it allows before saving it.

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

The weekly digest leads with the learning loop over the seven days before it runs: beliefs re-graded and what moved them, closeouts with their outcome and the learning each produced, and what is waiting on a decision (concluded tests the loop has not read, outside tests and studies owed a write-up, beliefs owed a re-grade). Each list shows five rows and links into Lyra for the rest. A quiet section says so in one line, and the pipeline follows.

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

Each person holds one role across the whole portfolio, not one per program. Owners and admins reach every program. Managers, editors, and commenters act in the programs they are assigned to, and managers can also read every other program.

• Owner. Full control of everything in Lyra, including granting owner and admin, deleting programs, removing people, provider secrets, and service keys. Lyra always keeps at least one owner.
• Admin. Works every program, manages people up to manager, and creates programs. Cannot grant owner or admin, delete programs or people, or touch provider secrets and service keys.
• Manager. Full control of assigned programs: the registers and moves through the lifecycle, settings, client configuration, gates, and who is assigned. Cannot delete a program or turn AI on.
• Editor. Client seat. Signs in to the client portal and reads the Results and Learnings of assigned programs. Writing from the portal comes later.
• Commenter. Client seat. Signs in to the client portal and reads the Results and Learnings of assigned programs.

People, in a program’s Settings, lists everyone who can reach the program, and anyone who can reach the program can read it. Managers and up add and remove people there by email. Someone with a Lyra account is assigned immediately at the role they already hold. Someone who has never signed in is invited, and the invitation turns into their assignment automatically on first sign-in.

A program’s People never changes a role, since a role holds across the whole portfolio. Rank rules apply where roles are set: owners set any role, admins set roles up to manager, and nobody else changes a role. Removing someone from one program leaves their role everywhere else as it was.

An owner can see Lyra the way a lower role sees it. On Account settings, View as, pick admin, manager, editor or commenter and choose Start. Lyra then shows what that role would see, in the programs you are assigned to at that role and read-only everywhere a real person with that role would only read.

A banner across the top says which role you are viewing as, with Stop beside it. Every change is refused while it is on, so nothing you click can change anything. It ends on its own after 30 minutes.

Starting and stopping are both recorded in the platform audit. It never touches your tokens, the CLI or a Claude connection, which keep acting with your own access.

From People on the rail: 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 (Account settings, in the account menu at the foot of the rail) 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.

Claude connects to Lyra as a connector. In Claude, add a custom connector with the address of your Lyra followed by /api/mcp, for example https://lyra.speero.com/api/mcp, then choose Connect. Lyra asks you to sign in with Google if you are not signed in already.

The consent page names the app, asks which programs it may reach, and shows at most five boxes for what it may do. All programs is the default and covers every program you work in, including ones you join later. Pick one program instead to keep the connection to it. Only reading and editing start ticked. Tick anything else it asks for, or leave it off.

With all programs connected, ask Claude which program you mean, or name it by its client code. Claude lists the programs it can reach and acts in one at a time.

An app can never do more than you can. If your access to the program changes, the connection changes with it on its next call.

Claude only sees the tools your connection can use. With reading alone ticked, no tool that changes anything is listed at all.

Every connection is listed under Connected apps on your account page, with Disconnect beside it. The Claude desktop app takes the same steps, under Settings, Connectors. Claude Code and other MCP clients have their own topics below.

Last verified: 2026-09-23, in claude.ai in a browser against Lyra staging. The desktop app is not yet verified. This Lyra runs 0.24.1.

Claude Code connects over HTTP with the same sign-in and consent page as Claude. In a terminal, run: claude mcp add --transport http lyra https://lyra.speero.com/api/mcp, using the address of your Lyra.

Then start Claude Code, type /mcp, pick lyra and choose to authenticate. Your browser opens the consent page, and Claude Code holds the connection from then on.

For a script or CI job with no browser, mint a personal token on your account page and pass it as a header instead: claude mcp add --transport http lyra https://lyra.speero.com/api/mcp --header "Authorization: Bearer <token>".

Last verified: not yet verified. The steps follow the MCP door as built, and nobody has walked them in Claude Code yet. This Lyra runs 0.24.1.

Any MCP client that speaks streamable HTTP can connect at the address of your Lyra followed by /api/mcp. The door answers POST only, one message or a small batch at a time, with no stream to keep open.

A client that supports OAuth finds everything from the door itself: its sign-in challenge names /.well-known/oauth-protected-resource, the client registers itself, and you sign in and consent exactly as with Claude. It must use PKCE. Its access lasts 60 minutes and refreshes from there.

A client with no OAuth takes a personal token from your account page as a bearer header. Either way a token answers up to 120 calls a minute by default.

Last verified: not yet verified with a named client. This Lyra runs 0.24.1.

After every deploy, or whenever Claude seems to have lost Lyra, ask Claude: run the Lyra connector test. Claude calls the connector_test tool, which every connection has, and it answers these lines in this order.

• Lyra connector test
• Version: the version Lyra is running, then the commit it was built from
• Host: the address of the Lyra it reached
• Connected as: your name and email, or the name of the service key
• Reach: all programs, or one program with its name and client code
• Programs reached: how many programs the connection can act in right now
• Tools listed: how many tools this connection shows Claude
• OK

Service keys (Admin, Integrations, Developer) 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. It opens your browser, you sign in and pick a program, and the CLI keeps itself signed in from then on. Pick one program for the CLI, and use lyra login --profile <name> for another. lyra login --token still takes a personal token for scripts and CI. 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, at the foot of the program rail, shows the sections your role reaches: General, People, Lifecycle (gates and sub-stages), Automations, Connections (Slack, ClickUp, API tokens, and share links), AI and agents, Data (backups and duplicate), and the Danger area. Each section folds to one line with its current value, so the page reads as a summary, and opens with a click. Everyone on a program reaches People and AI and agents, to read them.

General holds the client configuration (name, client code, slug, status, SOW renewal, register visibility, field labels, identity). It is manager and up. Changing the client code re-labels every Test ID and warns before it does. The digest channel is under Connections.

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, assets, and delivery, the results on tests, the tests and studies each delivery item covers, and the outside tests and studies a program cites, and deleted experiments and research come back under their original IDs. A live test keeps its pre-registered fields, and an approved test its pre-commitments, test type and margin, as they stand now, because a restore goes through the same locks as any other edit. Variable links, external links, comments, attachments, saved filters, 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 an agent, 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. It leads the AI and agents section of Settings, above which agents run in the program, what they remember there, and their runs, and changing it takes an owner or an admin. The deterministic automations are not AI and run regardless. Agents are set up in Admin.

Duplicate sits under Data, beside the backups, and the last section of settings holds the two actions that remove what a program holds. All three are owner only, and strip and delete ask you to type the client code before they run.

Duplicate builds a second program from this one. Structure only gives you the empty shell (settings, members, gates, sub-stages, variables, saved filters, SOW budgets, and the goal tree) with numbering starting at 1. An exact copy brings everything too. Copied automations arrive switched off, and API tokens, webhooks, share links, the digest channel, file attachments, and scenarios are never copied, so a copied touchpoint starts with no scenario linked. Every link in the copy points inside the copy.

Strip register data 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, Data, Deleted 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.

Outside a program the rail shows Portfolio, then Usage, People and Admin for owners and admins, with Help at the foot. Everyone else sees Portfolio and Help.

• Usage. Who used Lyra each week, through the app, the Claude connector or the CLI, with reads, writes and Claude calls as separate numbers. The list by person is not a productivity score. The feedback inbox sits below it.
• People. Everyone who can sign in, with search and filters. Change roles, add or remove program assignments, suspend, or remove from Lyra.
• Admin, Integrations. The agent registry and its runs, webhook subscriptions, and Developer: service keys, connector clients and connections, and encrypted secrets for intelligence providers.
• Admin, Security. The portfolio audit trail, every deck share link in one list, and Security, owners only: what is reachable right now, by whom, and the controls to shut any of it off.
• Admin, Data. GXOS conformance checks and deleted programs that can still be restored. What a study usually takes is set on the Library’s Research methods page.
• On the Portfolio, owners and admins get New program, which starts blank, as a duplicate of a program, or from an Airtable base, and an All programs view that lists every program with its people and AI setting, closed ones included.

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 way in: anyone with the link can submit an idea, no account needed. A learning card or a research brief can also be shared as a read-only link that needs no account.

A client seat (editor or commenter) invited at an address outside speero.com signs in to the client portal with Google, then with a code from an authenticator app, once an owner opens client sign-in in Admin, Security. A client sees the Results and Learnings dashboards of its own programs, read-only, and nothing else: no internal notes, no raw registers, no member emails. A client sign-in ends after seven days.