Skip to main content
Recommendations are durable opportunities on an existing workstream. They state property or business fit, why now, unknowns, the strongest alternative, what would disprove the idea, and the next bounded action. They can improve, expand, hold or stop work when evidence supports that course. No uplift score or recommendation quota substitutes for evidence.

​
Ownership and review

The development portfolio owns the recommendation cards and compares opportunities across its declared campaign children. Campaign interventions keep that same card home and name the campaign as execution owner. A campaign ledger exposes its actual parent_portfolio references for this handoff; it cannot create a second hidden recommendation under the campaign. An operator suggestion may start as portfolio research. Before preparation, curation can bind that same card to the appropriate declared campaign child while retaining completed root research. Active research must settle first; preparation freezes the binding. A campaign-bound card cannot switch to another campaign. Each execution owner retains its own scope and finite automation allowance. Recommendations do not create a workstream, scheduler or second assignment engine. The existing reconciliation pass consumes the recommendations and review cursor in its ledger. Broad opportunity discovery is due weekly, or earlier when material evidence changes. Existing requests and returned work continue on each pass. A completed review can produce zero new ideas. At most three opportunities without linked work can await a start; saving a research request does not evade that cap. Sources are retained, scoped Knowledge packets or pages. Live datasets supply research inputs; query findings are retained in the packet. The server pins source content and rereads that basis before private test preparation. Draft research can justify investigation; test readiness needs an approved factual source or the exact accepted research result. A method is not factual evidence or a performance forecast.

​
Research, preparation and approval are different facts

Suggest saves an input. Research and Prepare save durable intent and wake the declaring coordinator; they do not prove that a worker started. The coordinator uses the existing assignment engine and reviews actual returned handles. Completed work is not automatically accepted. Research and preparation keep separate assignment links. Dispatch uses the exact server-issued research_dispatch_key or preparation_dispatch_key. Native dispatch atomically attaches the assignment and increments the card revision; reread it after dispatch. A legacy explicit link specifies assignment_phase: "research" or "prepare". Repeating a current request reuses work. An explicit retry after terminal failure or rejection creates a new phase generation while retaining earlier links in history. Preparation produces a concrete private proposal, including scope, treatment, measurement, duration, limits and stopping conditions. Accepted preparation can request the existing native approval workflow, but the root coordinator cannot file a child provider approval under the root’s approval context. request_approval creates the server’s execution_generation and execution_dispatch_key; it is durable intent, not execution. The root dispatches the third native execute assignment to the exact ExecutionWorkstreamID with that key, the native expected_result_kind: "action_request", the unchanged accepted preparation packet and the child’s finite allowance. Native dispatch atomically attaches the actual execution assignment; a legacy explicit link uses assignment_phase: "execute" with the fresh revision. The detached worker uses the exact child scope and existing approval gates, which pause and resume it; the root never repeats the provider tool. No child recurring heartbeat or second assignment engine is needed. approval_id names an actual approval request from this recommendation’s scoped execution run, not a decision identifier. An unrelated approval from the same campaign cannot establish this recommendation’s progress. The canonical projection discovers all approvals for the exact execute attempts, organization and execution workstream using the native exact-run association. A partial failed batch may recover only when every recorded member has a known terminal outcome; failure can otherwise hide an in-flight or unknown write. Earlier successful receipts are retained and must not be replayed. Every discovered approval must have a succeeded receipt and the execute assignment must be completed and accepted before execution is succeeded. Zero approvals or an approved-only state never proves execution. Retries remain bounded and a failed partial provider write is never auto-replayed as a duplicate execution. Existing executor tools, approval runner, and native assignment review/result receipts own the workflow. Approval, confirmed execution, and experiment measurement remain separate; a saved setting or research allowance grants no media spend or provider write authority. The returned stage is derived from real linked assignments, all discovered approval and execution receipts, and experiment records. A successful execution also needs post-execution primary-metric evidence for an elapsed window ending before the experiment decision, from an actually readable, scoped retained Knowledge packet, with the observed outcome. A fabricated source identifier or a future window cannot establish measurement. Missing measurements remain unknown or inconclusive; a completed run or approved request is not a measured win.

​
Recovering failed execution

An in-flight or queued worker recovers through the native assignment. Terminal failed, cancelled or rejected execution needs an explicit recovery reason and finite allowance before another generation can be requested. Pending approvals and active tests must first be resolved. Earlier assignments and actual approvals remain available in previous_executions. Read actual provider state and earlier receipts before retrying; successful writes must not be repeated. A materially different treatment needs changed-evidence reconsideration and fresh preparation. Recovery intent never grants spending or provider authority; the worker still reaches the native gates.

​
Decision memory

Pass retains its actor, optional reason and pinned source basis. It cannot cancel active work implicitly. Rewording a title, changing source order or checking again does not reopen it. Reconsideration requires the current revision, changed pinned evidence and an explicit explanation; it returns to research.

​
API, MCP and CLI

Read recommendations and recommendation_review from GET /v1/workstreams/:workstreamSlug/ledger. The ledger also exposes outstanding assignment reservations separately from spent allowance. Write through POST /v1/workstreams/:workstreamSlug/recommendations. Actions are suggest, curate, research, prepare, request_approval, pass, reconsider, link and complete_review. Existing-record mutations require expected_revision. Organization, actor and source readiness are derived by the server. The MCP tool is erdo_manage_workstream_recommendations with {workstream_slug, input}. The CLI reads the same ledger and sends an exact JSON mutation file:
Live datasets remain declared research inputs. To cite a measured finding, retain the scoped query, actual result and denominators, observation window and snapshot reference in a versioned private Knowledge packet, then pin that packet as card evidence. A live dataset storage-item identifier does not certify immutable rows. Dispatch keys include the immutable recommendation UUID, phase and generation; matching prose keys in different declaring owners cannot share work. Native dispatch locks the declaring owner before the execution child and atomically links the assignment, so pass and dispatch cannot both win. Changed proposal content or pinned evidence invalidates settled private preparation; it must be prepared and accepted again. An execution cannot move backwards into research/preparation. Experiment links are admitted only after a scoped execution assignment exists. The native measurement recipe continues to own metric readings. After its window, retain an outcome Knowledge packet containing the actual observation references, query/results, denominators and limitations. Attach it to the owner and link it with measurement_evidence on the recommendation. The source is hydrated and pinned, and must have been created after the observed window. This joins existing readings without manufacturing another observation; a changed source needs reassessment. Explicitly inconclusive experiment decisions remain inconclusive.