Plans and approval

A plan describes the agent layer WeHarness proposes for a project. You can write the brief in any language; the plan is written in the same language. It covers the requirements, the acceptance tests, two to four candidate designs, the selected design, the implementation steps and the scope the build may touch. In a session, ask WeHarness to build something, in your own words, or type /plan. A coding tool starts one over MCP with plan_propose.

Who decides what

Several parts each have one job:

Part	Its job
Planner model	Drafts the requirements, acceptance tests, candidate designs and the detailed plan. It proposes and never decides.
Deterministic checks	Decide which candidates are eligible. They are code, not a model.
Elephant-1	WeHarness’s decision model. It answers bounded questions about the options it is given: is the brief clear enough, which eligible candidate fits best, is the evidence sufficient. It never writes plans or code and never approves anything.
You	Answer the clarifying questions and approve, or decline, the plan.

How a plan is built

1. Context. WeHarness compiles a bounded packet from your brief, your answers and the project’s indexed context: dependency facts, compatibility findings, the README and search results. Repository text is treated as data, never as instructions.
2. Requirements and acceptance tests. The planner extracts requirements, marks which are mandatory and where each one came from (the brief, or inferred), and writes acceptance tests. Every mandatory requirement gets at least one test.
3. Clarifying questions. WeHarness asks before drafting candidates when the brief itself states fewer than two mandatory behaviors, or when Elephant-1 judges that a stated behavior is ambiguous or that the brief leaves out what the agent must do. It asks at most three questions, each with a default assumption. You can answer them or continue with the defaults. Either way a new plan version starts, and questions you have answered are not asked again.
4. Candidates and checks. The planner proposes two to four candidate designs. The checks then give every candidate a result for every constraint.
5. Ranking. If several candidates are eligible, Elephant-1 chooses among them. The option order is randomized and recorded, and the question is asked once more with the order reversed. If the two answers differ, the choice depends on the order rather than on the options, so both are shown for you to choose. If only one candidate is eligible, ranking is skipped and the plan says why. If none is eligible, the plan stops at a compatibility gap that lists the failing checks.
6. Assembly. The planner writes the detailed plan for the selected candidate. The plan is validated against the architecture-plan schema: references must resolve, steps must not form a cycle, and every mandatory requirement needs both a step and a mandatory test. The plan then waits for approval.

Changing a plan

Ask for a change in the session, in your own words. WeHarness writes a new version of the same plan.

What you required stays required. Each requirement or constraint you stated gets a stable key the first time it appears, and every later version must carry it, restated if needed. A requirement leaves the plan only when a newer message of yours drops it. The plan panel marks your own requirements as Yours and lists what was dropped at your request.

If your messages are longer than the planner’s brief holds, the plan’s context notes say how many were left out. Requirements that earlier versions recorded are carried either way.

Cancelling a plan

While a plan is being prepared, Cancel planning beside “Preparing the plan” in the session (or in the Progress panel) stops it. The session shows Cancelling the plan until the work has stopped, then says in the chat that planning was cancelled. A cancelled version can never be approved, and earlier versions stay as they were: one that was ready for approval still is. A cancelled plan uses no credits. A plan that has already finished cannot be cancelled.

Credits

A plan version uses what its planning used: at least 5 credits (the planning fee) and at most 25. On your workspace’s own model key it uses 5. A plan that only asks you questions, and a cancelled plan, use none. Each decision Elephant-1 makes between options uses 1 credit. See Credits and usage.

The checks

Constraints from your brief are listed as C1, C2 and so on. The platform adds its own constraints:

Check	A candidate fails it when
C90 Catalog	It names a component that is not in the catalog release, or one that is on hold or withdrawn.
C91 Compatibility	A blocking compatibility finding (see Catalog and compatibility) affects a component it uses.
C92 Language	In an existing project, it moves the code to a different language.
C93 Effects	A write or notify tool the model can call has no idempotency strategy. This is checked on the assembled plan.
C94 Coverage	A mandatory requirement has no stated mechanism.

A constraint from your brief that code cannot check stays unknown, with the planner’s claim shown beside it. When the planner itself reports that a candidate breaks a constraint, the candidate fails that constraint.

Reading the result

Result	Meaning
Recommended	Elephant-1 chose a candidate and judged the evidence sufficient.
Near tie	The top two candidates are within 10 percentage points. Both are shown. The plan follows the first one; Plan with this option writes a new version for the other.
Your choice	You chose another eligible option. The plan records Elephant-1’s original choice next to yours.
Exploratory	Elephant-1 judged the evidence insufficient to choose. Treat the plan as a starting point, not a recommendation.
Single eligible option	Only one candidate passed the checks, so ranking was skipped.
Compatibility gap / No adequate option	No plan was assembled. The failing checks or the reason are shown.

Elephant-1’s probabilities are raw and uncalibrated: they are not success rates. The thresholds (0.5 for yes or no questions, 0.30 for “the brief leaves out what the agent must do”, 10 points for a near tie) are documented starting values. The 0.30 value was checked on labelled briefs in five languages. The recommendation text always starts with the decision record, which says who chose and with which probabilities. The planner’s own explanation follows, labelled as the planner’s.

Every decision is recorded with:

• the rubric and its digest;
• the option order and the seed used to shuffle it;
• the full answers;
• the model used, its usage and its latency.

If the decision model is unavailable

WeHarness retries once straight away, then again after 1, 5 and 15 minutes. After that the run shows Paused: dependency and retries every 30 minutes. It continues where it stopped. There is no fallback model: a plan is never ranked by something other than Elephant-1.

Approval

Only owners and admins can approve, and only in the signed-in web app. API and MCP clients cannot approve, so a model can never approve its own plan. MCP offers plan_propose and plan_get but no approval tool.

Approving binds three things:

• The exact plan. Its digest is shown next to the version. If the plan changed since you opened it, approval is refused.
• The allowed scope. Paths, effects and what is forbidden, taken from that plan.
• The quote. It lists the planning’s model usage and expires 7 days after the plan was made. Approving reserves no credits: the plan version was counted when WeHarness produced it, and the work after approval is counted as it runs. See Credits and usage.

Approval is also refused when:

• a newer version of the plan exists;
• the quote has expired;
• the code the plan was made from has changed since (the session now reads another branch or commit, or a source was removed). Plan again to approve.

Approving a new plan supersedes the earlier approved plan of the same project. You can revoke an approval; the plan then returns to Awaiting approval.

In a session, approving is answered like a message: the session takes the plan’s task, and WeHarness builds the plan in the session’s draft, step by step within its scope, while you watch the work in the chat. When it is done, WeHarness sends the draft as the task’s report and verifies it in a fresh sandbox with the repository’s approved checks and scenario cases. Approving does not change your repository: WeHarness pushes only when you approve a push. A plan your coding tool asked for over MCP is your tool’s to build; Work on it in the cloud in the plan panel moves it to the session instead. See MCP server.