Plan to performance: a dashboard should lead to a recorded decision

A dashboard can tell me that delivery is late and spending is high without helping me decide what to do on Monday. The Plan-to-Performance loop is intended to connect goals, approved resources, actual results and a small set of decisions that change the work.

The prototype has strategic goals, measurable results, operating plans, forecasts and variance records. It can enforce a locked plan and demonstrate a review path for revisions. Live feeds from every business loop and a complete forecast model remain extension work.

Keep the baseline stable

Suppose the studio plans to deliver three pilots in a month with a fixed contractor budget. Halfway through, two are delayed by customer access and one needs more ingestion work. I do not want the system to edit the original plan until the variance disappears.

The approved plan remains the baseline. A reforecast is a new version with reasons, changed assumptions and a decision record. The prototype's plan-lock policy rejects an attempt to resubmit a locked plan and requires a sign-off condition before locking a pending one.

That sign-off path still needs authenticated evidence. The local policy can accept approval hints from request arguments or stored properties; production approval should resolve to a real decision bound to the plan version.

A variance needs a unit and an explanation

{
  "metric": "accepted_pilots",
  "unit": "count",
  "period": "2026-09",
  "plan": 3,
  "actual": 1,
  "forecast": 2,
  "evidence_refs": ["work-order-017", "work-order-023"],
  "candidate_causes": ["customer access delayed", "ingestion rework"]
}

The causes are candidates until supported by the relevant delivery records. The model can summarise those records and prepare an explanation; it should not invent a causal narrative to fill a blank dashboard.

A spending variance also needs its basis. Approved commitments, invoiced costs and cash paid can differ. I would show them separately rather than blend them into one “spend” line.

Separate observation, forecast and decision

The final row is essential. A generated recommendation is not a management decision, and a decision is not implementation. The platform should track whether the downstream work was accepted and completed.

A proposed weekly operating brief

For a solo founder I would begin with five questions: what was promised, what was delivered, what cash arrived, what needs a decision, and what changed since the previous review. Each answer should link to underlying records.

A useful brief might read:

Two customer reviews are waiting for access. One invoice is partially paid. The proposed contractor purchase is within the remaining delivery budget. The decision today is whether to approve that purchase or move the third pilot's start date.

This example is intentionally specific. It reduces the founder's need to assemble context across sales, delivery and finance before deciding.

Don't let the planner rewrite every other loop

A plan decision should result in governed actions. A budget increase does not give the planning agent direct access to the payment provider. A hiring freeze should create the relevant capacity constraint and review existing commitments; it should not silently cancel an accepted offer.

The prototype's planning package currently runs independently of the complete financial integration. The next implementation should connect actuals with stable event IDs, explicit metric definitions and a clear period boundary. Otherwise replaying a transaction can inflate both the dashboard and the recommendation.

The metric for the planning layer

I would measure how many decisions have complete evidence, how long critical decisions wait, and whether approved decisions reached their receiving workflows. Forecast error matters too, but it should be broken down by cause and horizon rather than hidden inside one aggregate score.

The first useful release can be a weekly brief and approval queue. It does not require a real-time executive simulator. If I can review the business faster and identify the one decision that changes the week's outcome, this loop has earned its place.

Forecast from obligations before inventing targets

A planning agent should know what the company has already promised. Start with accepted work, available capacity, expected receipts, committed purchases and unresolved risks. Goals can then be compared with that operating base. A target of “double delivery next month” is not a plan if the current commitments already exceed available hours.

For the studio, keep separate cash and capacity forecasts. A project can be profitable over its lifetime while creating a short-term cash gap. A large pipeline does not create delivery capacity. The planning view should show both constraints and the assumptions behind them.

from company_lab.business import reforecast

result = reforecast(
    actual_minor=300000,
    remaining_minor=400000,
    baseline_minor=600000,
)
assert result == {"forecast_minor": 700000, "variance_minor": 100000}

This is a simple additive example. The useful feature is that actuals, remaining estimate and baseline remain separate. Replacing the original plan with the new forecast would hide the variance the founder needs to understand.

Give every metric a definition and a time window

“Revenue,” “active customer,” “completed project” and “qualified lead” can mean different things in different loops. The metric registry should identify source records, inclusion rules, currency, period, freshness and owner. A planning agent must not compare an invoiced amount with a cash receipt target under one unlabeled total.

A proposed metric definition can be compact:

metric: accepted_delivery_milestones
version: 2
source_event: delivery.accepted
business_key: commitment_id + milestone_id
window: calendar_month
exclude: reversed_or_superseded_acceptance
freshness_limit_minutes: 60
owner: delivery

This is an implementation contract to be reviewed, not a claim that the current platform already computes every metric. The same definition should drive the dashboard and the evaluation fixture.

Explain variance through linked evidence

Suppose the delivery forecast slips by five days. The agent should distinguish missing customer access, underestimated parsing work and a provider outage. Each reason points to a work-order or incident record. The founder can then choose to reschedule, reduce scope by agreement, buy capacity or keep the original commitment with an explicit risk.

A variance narrative should not become a story generator that rationalises every outcome. Require source references for causal claims and label uncertain explanations as hypotheses. “Three tasks are blocked on customer access” is directly observable. “The customer is losing interest” requires different evidence.

The planning loop can propose actions in other loops, but those owners evaluate the consequences. A forecast improvement does not authorise sales to move a contractual deadline or procurement to purchase more capacity automatically.

Lock the plan without freezing learning

The current prototype demonstrates a locked plan and reforecast path. The implementation needs a real approval record behind the lock, plus a versioned snapshot of the assumptions. Future edits create a new plan version or amendment rather than mutating the accepted baseline.

For one founder, this produces a useful weekly rhythm: review actuals, inspect exceptions, choose a small number of changes and record the next check. The agent can prepare the material and follow up on chosen actions. It should not create a new strategy every time a daily metric fluctuates.

Test stale data and contradictory goals

The exercise is a dashboard whose sales numbers refreshed this morning but delivery capacity is three days old. The planning agent should flag the freshness mismatch before recommending another campaign. A second case sets a growth target that conflicts with the available founder review capacity. The correct output is a trade-off packet, not a confident plan that assumes unlimited supervision.

Measure whether the prepared review reduces time spent finding facts and whether the resulting actions resolve the recorded variance. The volume of generated plans is a poor proxy for better management.