Give every destination a deliberate place

A destination is assigned a navigation position with its rationale.

Give every destination a deliberate place

People should be able to find the screen or action they need. Its position in the application deserves a decision rather than becoming an accident of implementation order.

The placement plan records the destination, its intended surface and the reason for that choice. It can also record a deliberate decision not to place something, keeping that distinct from an omission.

Example — Make customer work easy to find

The team places the contact list in a customer-work section of the sidebar. The plan records why it belongs there before the application implements that navigation.

For engineers

Read a placement decision

This illustrative decision uses the current public shape. The surrounding plan must declare the grouped sidebar address. The origin value describes an attributed decision, not proof that a review took place:

import { PlacementDisposition, PlacementDecisionOrigin, PlacementSubjectKind, PlacementSurface,
  type PlacementDecision } from '@wildo-ai/saas-specifications';

const contactListPlacement: PlacementDecision = {
  decisionRef: 'placement-contact-list',
  disposition: PlacementDisposition.PLACED,
  origin: PlacementDecisionOrigin.DELIBERATED,
  subject: {
    kind: PlacementSubjectKind.RESOURCE_OPERATION,
    moduleRef: 'relationship-records',
    resourceRef: 'contact',
    operation: 'list',
  },
  address: {
    surface: PlacementSurface.SIDEBAR,
    groupRef: 'customer-work',
    order: 10,
  },
  rationale: 'Keep shared customer records beside the work that depends on them.',
};

A placed decision carries an address. A declined decision carries its reason without an address. A revision records the rationale it supersedes, preserving the distinction between the original judgment and the changed one.

Use the surface’s actual structure

Surface	Address structure
Sidebar and settings hub	Named group and order
User menu and command menu	Flat placement and order

The validator checks the plan’s supported structural rules and reports coverage or ordering concerns. The semantic authority supplies the known engine settings destinations, so unknown engine destination references can be rejected. Application view and resource-operation existence need their own consumer context; do not infer those checks from the engine catalogue.

Inspect an application-owned plan

Wonder Todos exports applicationPlacementPlan from its specifications package and supplies it through placementPlanSpecification in the companion export. Its plan places the task list in the personal-work sidebar group and explains the triage purpose behind that decision. This is an existing application declaration; the contact example above illustrates the same contract with a different product.

The plan is a specification of placement, not automatic menu rendering. Apply the decision through the relevant shell configuration and review the resulting destination, labels and access behavior. A rationale explains the product choice; the rendered application establishes whether it is usable.

Give every destination a deliberate place