Skip to main content

Use Measure and Time Plans

Before you start​

Measure requires tenant-admin or measurement read access. Projects, observations and runs must already exist for populated results. Start with Create a measurement project, Import observations, and Run forecasts using the supported SDK/API. The main Measure page displays these results; it is not a project-creation form.

Read a forecast​

  1. Open Measure (/measure). Check the tenant and generated time.
  2. Read the project target, observation count and headline before the chart.
  3. Inspect forecast snapshots and the evidence disclosure. Compare the recorded range with the target/deadline rather than treating a median as a promise.
  4. Use Calibration to inspect resolved outcomes and containment history; use Decisions for available simulation/value-of-information results.
  5. Review import rejection rows, query history and resource runway when supplied.

Example: for a target of 100 completed points, compare the recorded forecast with that target and inspect the observation count. Expected result: server-owned values with ready, sparse, partial, uncalibrated or unavailable state. Sparse or uncalibrated evidence does not justify a confident decision. Missing intervals must not be filled in by hand. Correct rejected observations through the import workflow and run a new forecast instead of editing historical results.

Plan, run and review time​

Open Time plans from Measure (/measure/time-plans). Read access uses timeplan:read; drafting requires timeplan:write; executing requires timeplan:run. Tenant administrators have these journeys available.

  1. In Plan, choose an existing plan or edit a draft's name, horizon and blocks. Validate it and inspect the server allocation before creating the plan.
  2. Open the plan's run workspace and create a run from the frozen plan.
  3. Use the available run controls to start and progress through blocks. Only commands valid for the current state are available.
  4. In Review, inspect completed/skipped blocks, overrun, recorded adjustments, prediction snapshots and the completed report when the run is terminal.

Example: create a short practice plan with two blocks inside its horizon, validate the allocation, run both blocks, and inspect their recorded actual durations in Review. The server owns timing and allocation; a browser countdown is a projection, not the authoritative record.

If a command fails or conflicts with another controller, refresh the same run and inspect its current state before trying again. Keep its UUID; do not create a duplicate run to hide an error. A completed report is unavailable until the run reaches a terminal state. Read-only users cannot validate drafts or run commands.