Initiatives.

An Initiative is one outcome over a scoped part of your system, pursued through more than one hypothesis. What one holds, how research runs on it, and what its page shows.

What an Initiative is

An Initiative exists when its outcome can be pursued through more than one plausible hypothesis. Some hypotheses validate, some fail, and some become irrelevant as the system or the research changes. That is normal progress for an Initiative.

• Initiative. The outcome, its scope, its constraints, and why the program matters.
• Hypothesis. One falsifiable claim that could advance or invalidate part of the Initiative.
• Case. The work on exactly one hypothesis.
• Candidate. One tried change, measured inside that case.
• Pull request. The publication of an accepted candidate.

An Initiative is not a large case: a case does not accumulate several hypotheses because they serve the same outcome.

What it holds

An Initiative holds a title, the outcome it seeks, and the rationale for why that outcome matters in this system. Its disposition is proposed, active, paused, or settled, with an optional reason once it is settled; over MCP those values print upper-case. Targets and exclusions name entities on the model: a repository, a service, a data store, a workload, an environment, a component, an entry point, a path, or a hop. They may not name the same entity; Perfloop rejects that scope.

An Initiative needs an accepted model to scope it. A repository's code and architecture model is enough; production telemetry is not required.

Creating and changing one

The web reads Initiatives; it does not author them. The Initiatives page says Create through Perfloop MCP: a contributor uses a connected coding agent to start research on an outcome, and the first research run creates the Initiative. startResearch with a title, an outcome, a rationale, and a repository creates it as proposed, and the first accepted research Session activates it.

editInitiative replaces the title, the outcome, the rationale, the disposition, the settled reason, the targets, and the exclusions in one version, against the version you read. A stale version is rejected, and a settled Initiative does not reopen. A research Session running when you edit stops before its next step; start another with startResearch or wait for the workspace cadence.

Perfloop checks the title, the outcome, and the rationale before it saves them. Text that fails is not saved: the error is INITIATIVE_REFUSED, and each of its findings names the rule, the field, the words that broke it, and what to change. The rules are outcome_testable (the outcome names its target, scope, and the evidence that ends it), direction_not_procedure (give direction, not steps for the cases), no_silent_narrowing (no case has to clear a bar the outcome does not set), and current (no step is made mandatory for a named Session, case, or candidate). When the check cannot run, the error is UNAVAILABLE and nothing is saved.

Each check is billed to Usage like other model use. When Usage cannot cover it, the error is USAGE_EXHAUSTED or CARD_REQUIRED. The Usage page totals each day's checks as Initiative check.

initiatives reads them. Without an id it lists them with the workspace research cadence; with an id it returns a summary, and a section reads one part of it: scope, cases, runs, decisions, sources, code, telemetry, or alternatives.

Research

One research Session runs against one active Initiative. A contributor starts it with startResearch, or the workspace cadence takes its turn. It reads the connected repository, papers, and public code, and it can read the telemetry you configured. It saves each hypothesis it admits, with its case, and at most one case it recommends running next. While it runs, the Research section shows Research in progress; a Session that stops early keeps what it saved and shows Research stopped incomplete with the reason. Each run is billable. The cadence is set on Autonomy and limits.

A hypothesis can require another hypothesis in the same repo. Its case waits until every prerequisite has a merged case.

When the outcome names a fixed set of inputs to improve, such as pinned benchmark cases, research can propose work on exactly those inputs. A reported gain still needs independent verification.

The recommendation opens under Why this was selected, with the experiment it proposes under Proposed test. When a run recommended nothing, the page says No Case recommended yet.

Direction

Triage, case work, and verification read an Initiative's outcome, targets, and exclusions. An edit reaches the next case, not one already running. An Initiative cannot lower the proof bar. A research Session can recommend a change to the direction; only editInitiative makes one.

What the page shows

The page shows the direction, the next decision, the scope, the hypotheses, the cases, and the research. Each case links to its result and close reason; the candidates and the pull request are on the case page. Retained decisions, marked Assessed · not published, are assessments no published result carries. Other ideas holds the alternatives a run rejected or deferred.

Failed and inconclusive cases stand beside the wins. The page shows no percentage complete and no health score.

Also in this section: Quickstart, The loop, Case states, Pull requests, Steering and learning, Autonomy and limits, Members, and The MCP server.

Questions: hello@perfloop.ai