Browse documentation
Docs/Build

Project a resident plan as a Gantt schedule

Connect a canonical Planning region to a Calendar surface through wireBindings, then inspect relative-time lanes and solve evidence.

Watch it in Grid

See the concept in Grid.

Use the film for the product interaction and this article for the complete contract and reference detail.

Companion film

The schedule solves itself

Resolve a source-authored Planning region into relative-time resource lanes, then reveal the makespan, objective, and repair evidence behind the schedule.

59 secGrid 0.63.2
Open film page

Project a resident plan as a Gantt schedule

Grid 0.63.2 supports a same-model authoring route from canonical Planning source to the released Gantt renderer. A structured model can declare its real planningRegions, publish the Calendar surface slots through wireBindings, and retain both contracts in one compiled model. Grid then discovers the named Calendar surface and resolves the selected resident Planning region without translating the source into formula text or substituting demo assignments.

This guide is pinned to Grid 0.63.2 and verified against Grid Core commit ab1068ba7fc3557b50bad15cf09263f83006f332.

Author the same-model bridge

Canonical JSON publishes named workbook wires by mapping each public symbol to an existing cells[].cell_id. The two core Calendar slots and the Planning region belong in the same source document:

{
  "cells": [
    {
      "cell_id": 1,
      "expr": { "kind": "string", "value": "calendar" }
    },
    {
      "cell_id": 2,
      "expr": {
        "kind": "string",
        "value": "version = 1\nkind = \"calendar\"\ntitle = \"Factory schedule\"\n\n[planning]\nenabled = true\nregion = 0\nunit = \"hours\"\n"
      }
    }
  ],
  "wireBindings": {
    "Schedule!type": 1,
    "Schedule!config": 2
  },
  "planningRegions": [
    {
      "activities": [
        {
          "id": "prep",
          "duration": 2,
          "resource": "dock",
          "predecessors": []
        },
        {
          "id": "run",
          "duration": 5,
          "resource": "mill",
          "predecessors": ["prep"]
        }
      ],
      "nodeBudget": 1000
    }
  ]
}

This is a supported canonical-source contract, not a workaround:

  1. The compiler validates every wire name and target, rejects missing cells and case-insensitive conflicts, and writes the named-wire table into the compiled artifact.
  2. Deployment retains that compiled wire table. Restart hydration recovers the names from the artifact, so canonical JSON does not need to be reparsed as Grid-text assignments.
  3. Surface discovery combines the compiled names with the canonical source, reads Schedule!type as calendar, and resolves Schedule!config from the same model.
  4. [planning] enabled = true selects the resident Planning renderer. The surface calls the real Planning resolve route for that model and projects the returned report.

For a full industrial fixture with alternative resources, calendars, changeovers, optional work, due-date cost, and declared Frame/Table outputs, use Grid Core's examples/planning/job-shop.json.

Choose Calendar or resident Planning

Both modes use a Calendar surface, but they have different contracts:

Need Use Interaction contract
Schedule date-bearing events in month, week, day, agenda, or timeline views Ordinary Calendar Bound events can be dragged or resized when their date fields are writable. The edit writes back to the bound model cells.
Inspect the result of a source-authored scheduling problem Resident Planning Grid resolves a Planning region and projects its assignments as relative-time Gantt lanes. The bars are solve results, not draggable Calendar events.

Resident Planning does not translate abstract solver units into dates. If the model schedules in hours, shifts, or another unit, use that same word as the display label and keep the numeric values unchanged.

For ordinary event authoring, use the Calendar contract. Continue here when the model owns a canonical Planning region and publishes its Calendar surface through named wires.

Configure the projection

The Calendar configuration contract is:

version = 1
kind = "calendar"
title = "Factory schedule"

[planning]
enabled = true
region = 0
unit = "hours"

enabled = true selects resident Planning instead of the ordinary Calendar renderer. region is a zero-based position in the array of returned Planning reports; it is not the report's global LIR regionId, which may differ when another dialect region precedes Planning. unit labels the axis, bars, and setup tooltips; it does not convert schedule values.

The surface resolves the selected region when it opens. A model without resident Planning regions, or a position outside the returned report array, produces an explicit error rather than sample assignments.

Review a plan

  1. Deploy canonical source containing both planningRegions and the Calendar wireBindings shown above.
  2. Wait for model hydration, then confirm that the workbook exposes the named Schedule surface. A missing tab means the source failed compilation, the compiled named wires were not returned, or the type/config cells do not satisfy the Calendar contract; it is not a reason to create a separate formula model.
  3. Open Schedule and confirm that the header says Resident Planning · region 0 and Relative-time resource schedule · hours.
  4. Read each resource lane from left to right. A hatched reservation immediately before a processing bar is sequence-dependent setup time.
  5. Inspect the solve evidence in the header. It identifies the returned status and the work the solver reports.
  6. Expand Assignment table to review activity, resource, due, tardiness, cost, setup, start, end, and duration values.
  7. After changing a scheduling input through a model-owned input, canonical source replacement, or another supported Planning workflow, choose Resolve plan. Do not drag a result bar to make that change.

The manual action solves the current resident model again. When resultsFrame or resultsTable is declared, each successful solve replaces the prior published generation atomically, so repeated resolves do not append duplicate schedules or expose an empty intermediate table.

Read the visible evidence

Evidence What it establishes
Status The returned solve state. An infeasible result remains No feasible schedule rather than becoming a demo chart.
Makespan and objective The returned schedule horizon and objective value. Soft cost appears separately when nonzero.
Omitted The number of optional activities the result did not admit. Hover the evidence to inspect their identifiers.
Nodes The solver's explored-node count for this result.
Incumbent and repair labels Whether the solver reused an incumbent or attempted affected-cone repair, including retained and repaired assignment counts when available.
Local passes and local nodes Deterministic large-neighborhood-search evidence when the result reports repair iterations.
Resource lanes Assignments grouped by resource, with setup and processing spans on a relative-time axis.
Assignment table The exact per-activity due, tardiness, cost, setup, start, end, and duration values returned for the selected region.

Do not infer a guarantee from one badge alone. Review the returned status, objective evidence, omissions, and assignment rows together.

Boundaries in Grid 0.63.2

  • wireBindings exposes a canonical model's existing cells under public names; it does not create or edit the Planning region.
  • For canonical JSON, author the Calendar cells, wire bindings, and Planning region in the same source. Do not create a separate formula model or assume that a surface-creation action will splice fields into structured JSON.
  • This is a result projection, not a Planning-region editor. Planning bars do not provide the ordinary Calendar's drag, resize, or date-field write-back behavior.
  • Resolve plan reruns the current resident problem. Change inputs, source, or Planning state through an authorized model workflow first.
  • The surface does not coerce schedule units into dates or time zones. The unit setting is a label.
  • Missing regions, solve failures, infeasible results, budget-exhausted results, and empty assignment sets remain visible states. There is no fabricated fallback schedule.
  • The surface shows one zero-based report position at a time. Do not confuse that position with the report's global regionId.
  • Solver evidence describes the returned execution. It is not a proof of business feasibility beyond the constraints authored in the Planning model.

Deterministic 0.63.2 film evidence

The schedule solves itself demonstrates this released route in the real Grid UI. Its source-bound capture:

  1. Deploys the byte-identical canonical examples/planning/job-shop.json fixture with one planningRegions entry and Schedule!type / Schedule!config wire bindings.
  2. Discovers and opens the source-authored Schedule tab on that same disposable model.
  3. Observes the real POST /api/models/:id/planning/resolve response without intercepting or replacing it.
  4. Checks the returned assignments against the authored activities, resources, duration, due-date, setup, makespan, objective, and node evidence.
  5. Matches those returned values to the visible resource lanes, setup reservation, evidence badges, and assignment-table row before release.

The film proves that the canonical bridge and resident projection are publishable in Grid 0.63.2. A screenshot, intercepted response, sample assignment array, or Planning region in a different model would not satisfy the same contract.