Identity demand analysis

Stage 2 · Analysis

The operator jobs behind Identity searches

Interpret observed language, identify required evidence, and preserve record authority before proposing Tools.

  1. 1

    Maintain the real-world Place

    Maintain the venue name, address, coordinates, phone, website, hours and Place media used wherever that location appears.

    A Kitchen links to Place by place_id. It does not copy a Place object or shadow these fields.

    Authority: Place

  2. 2

    Maintain the Kitchen root

    Maintain the Kitchen name, slug, lifecycle status and visibility that identify this Kitchen entity and its publication state.

    These are Kitchen fields. They do not absorb venue address, contact, hours, media, fulfilment or theme.

    Authority: Kitchen

  3. 3

    Link the correct authorities

    Create, select or replace the Place linked to the Kitchen while preserving both entity identities and permissions.

    Relinking is a consequential compound action. It must not clone one Place into Kitchen or silently rewrite a shared Place.

    Authority: Kitchen link plus Place authority

  4. 4

    Publish an honest projection

    Preview and publish the joined Kitchen and Place presentation with explicit visibility and missing-field evidence.

    The projection may derive display fields for a page or directory; derived transport is not canonical storage.

    Authority: Kitchen publication composed with Place

Record map

Evidence the capability owns, references, or derives

kitchen.identity.kitchen

Kitchen

ownedavailable

Owner: Kitchen

Kitchen owns only its root identity, lifecycle and Place link.

  • id
  • name and slug
  • status and visibility
  • place_id

kitchen.identity.place

Place

referenceavailable

Owner: Place

Place owns venue identity, location, contact, hours and media; Identity composes it without copying it into Kitchen.

  • venue identity
  • address and coordinates
  • contact and hours
  • Place media

Required record questions

What must Identity make knowable?

  • Which Kitchen id and Place id are being composed?
  • Which entity owns every editable field?
  • Does the operator have authority to edit Kitchen, Place or both?
  • Is a displayed value canonical, joined, derived or missing?
  • Would changing the linked Place affect another Kitchen, Supplier or public surface?
  • Which visibility or lifecycle change is being proposed and what will it expose?
  • Which fields are required for this publication target rather than globally required?
  • Can previews and debug output preserve the visible Kitchen and Place separation?
Analysis conclusion
Kitchen Identity is a joined editing surface over two explicit authorities: Kitchen and Place. It must preserve that separation in storage, UI, debug, AI context and every proposed mutation.
Review proposed Tools