Demands

Recording and correcting

• When a demand is recorded — on the New demand page or by an agent with assess_request — CorPole names the open demands that look like it (the same word-overlap check as for duplicate requirements and defects). If it is the same request, close one as not pursued or link both to one initiative.
• A demand recorded later keeps the day it came in: on the form, or received_at for an agent. Waiting and flow time count from that day; a date in the future is refused.
• The person who recorded a demand, or someone who manages the portfolio, can edit its title, request text, requester, channel and received date while it is open. Each change is written to its steps and the change history.
• Assess again against the solution chosen at the top: the assessment against that solution is replaced, the latest one against each other solution is kept below it, and the reassessment is written to the steps. Viewers and auditors cannot assess again.
• A demand linked to the wrong initiative can be taken off it with a reason (portfolio managers, on the demand or the initiative page). A demand left without an initiative goes back to Reviewing. The only demand of an initiative in Ready or Implementing stays while the demand gate is enforced: link the right one first.

Decision packages

• At four decision points — accepting a demand, choosing the mode, a re-decision and closing an initiative — CorPole shows a decision package: every option with its expected net value, cost range and risk, the evidence for and against, similar closed initiatives, the recommended option with its confidence, and what would change the recommendation.
• The basis is stated: expected net value first, then how bad the pessimistic case is, then delay. Tenant objectives and weights are not configurable yet.
• Choosing another option is allowed and never scored; CorPole only asks for a reason in a sentence. The decision, the package it was made on and the reason are kept under Decisions on the demand and initiative pages.
• For high-risk decisions (a solution, or a pessimistic cost of 1,000,000 or more) the package stays folded so you form your own view first; you can note that view with the decision.
• Agents read the same package with get_decision_package and talk it through; people decide.

Value case

• A demand carries a value case: the hypothesis, and an assessment of benefit, cost and time as optimistic / expected / pessimistic ranges, with confidence and evidence. An initiative without a demand can have its own.
• Each revision is added, never overwritten; the first intent (first hypothesis and first assessment) stays visible, so you can tell learning from a drift in intent. A narrowing cost range is shown as the work learns.
• Agents propose revisions from evidence (propose_value_assessment); a person who manages the portfolio accepts or rejects them. get_value_case reads the case.
• Re-decision thresholds are written when the demand is accepted: cost goes above an amount (default: the pessimistic cost), a leading indicator falls below a value (readings entered by hand), a time window closes, work touches a solution the initiative did not commit to, or the hypothesis changes.
• A crossed threshold opens a re-decision: continue, pivot or stop, with a reason. Stopping is a decision taken in advance, not a confession.
• Mode defaults: a project needs an accepted assessment and a threshold before Ready, and an open re-decision holds its next step; for small work it is a warning; urgent work has none (the post-incident review covers it).

After live: outcome reviews

• A value case does not end with Done. When its initiatives are closed and at least one is Done, the case goes live and outcome reviews are scheduled — by default on days 30, 90 and 180 (Tenant settings → Outcome reviews changes the days).
• When a review is due, the case's owner gets a notice. The review keeps the expected benefit and cost of the moment and the realized ones you enter; when the benefit cannot be measured yet, say why in the note.
• Each review leads to one of: close the case (later reviews are dropped), start a new demand, or propose a rollback — both open a demand in the Funnel with the numbers and your note.
• A case whose initiatives were all not pursued closes without reviews.

Recording a demand

• New demand: who asked, the channel (e-mail, meeting, ticket…), when it came in, and the request as it came. Each ask in it is assessed against the open solution — new, already there, partly there, retired before or in conflict — and the result is kept on the demand.
• Your agent records one with assess_request (it asks who it came from); list_demands and get_demand read them; track_requests shows everything that came from one person or unit.
• Any member may record a demand; viewers and auditors cannot. Agents record demands only in the Funnel.

The steps

Funnel → Reviewing → (Analyzing) → Ready → Implementing → Done, or Not pursued with a reason. The list shows how many days a demand has been in its step; a demand waiting in the Funnel or Ready for more than a week is marked. People with the portfolio permission link a demand to one or more initiatives in Reviewing and choose each initiative's mode (see Portfolio board).