Map

Map is the layer where you assign governance to the objects. It takes the Extract output (entities, personas, tasks) and commits the rules that map signals to UI decisions. Visual cues per entity trait. Pattern assignments per context. Mental models that capture cultural expectations. Priority rules that resolve conflicts. Map is the bridge between what the product is and how it looks.

What Map captures

Map commits four kinds of decisions, all in one file.

Visual cue assignments

One assignment per entity. Each assignment lists the visual cues that fired for that entity, based on its attributes and traits.

Each cue records:

• The trigger (e.g., "entity has a status lifecycle")
• The treatment (e.g., "status badges with semantic colors plus filter tabs by status")
• The scope (list views, detail views, forms, or all views)
• The strength (strong = always apply, soft = apply unless overridden)

Cues come from a library of rules that ships with Denote at the system level. They fire automatically when the entity's attributes match the trigger. You can also assign cues manually for traits the automatic rules did not catch.

Pattern assignments

One assignment per context. Context is any relevant combination of entity, persona, and task. Not all three are required.

Each assignment records:

• A short label for the view concept (for example, "Manager expense review" or "Home cook scaling a recipe").
• A description for the purpose of this context.
• The entity, persona, and task (any combination of the three that is relevant).
• The assigned UX pattern from the library of twenty.
• Pattern-specific configuration (density, emphasis, primary action, secondary actions, sorting, filtering, grouping).
• A rationale explaining why this pattern fits.
• Alternatives considered, with reasons they ranked lower.
• A review status (pending_review, approved, rejected, swapped).

Mental models

Cultural expectations the designer wants to honor or deliberately break. Each mental model has an expectation, a source (why users expect it), a strength (strong, moderate, weak), and an implication for the design.

Mental models override pattern matching by default. If the rules say table but a mental model says kanban, the mental model wins, unless a priority rule says otherwise.

Priority rules

The designer's explicit declaration of which rule wins when two rules conflict.

Rules have a scope:

• global, applies to all conflicts in the project.
• entity, applies to one specific entity.
• conflict, resolves one specific clash.

Each rule is written in natural language with both the rule and the resolution spelled out.

The canvas

Map renders as a governance editor. Three columns, one for each of the first three kinds of decisions, plus a panel for priority rules.

• Visual cues panel. Each entity appears with its fired cues listed below. You can see the trigger, treatment, scope, and strength for each cue. Soft cues can be toggled off. Manual cues can be added.
• Pattern assignments panel. The central working area. Each assignment is a card showing label, context (entity plus persona plus task where relevant), assigned pattern, configuration, rationale, alternatives, and review status. You can approve, reject, swap, or reconfigure any assignment.
• Mental models panel. A short list of cultural expectations. Each entry shows expectation, source, strength, and implication.
• Priority rules panel. A ranked list of conflict resolution rules, scoped globally, per entity, or per specific clash.

The canvas also shows visual indicators where rules conflict. If a Visual Cue and a pattern assignment suggest incompatible treatments, the conflict is surfaced so you can decide whether to add a priority rule or swap one of the decisions.

The file written

Map writes one file: design/governance.json. The top-level object has four arrays (visualCueAssignments, patternAssignments, mentalModels, priorityRules) matching the four kinds of decisions.

The file is machine-readable. A human-readable companion (design/governance.md) may be generated alongside it in future versions. For now, Claude Code reads the JSON directly.

The skill

/map is the skill that populates the Map layer.

Reads:

• design/intent.json, design/entities.json, design/personas.json, design/tasks.json (the Extract output)
• design/governance.json (if it exists, merges and preserves decisions already made)
• The system-level Visual Cue library and pattern library from intelligence/

Writes:

• design/governance.json

Behavior:

• Fires all matching Visual Cues per entity automatically based on attribute types and roles.
• Enumerates candidate contexts (entity alone, entity plus persona, entity plus persona plus task) and proposes pattern assignments for the ones that drive clear decisions.
• Explains rationale for every assignment. If the rationale is weak, proposes alternatives and asks you to choose.
• Flags conflicts between cues, between cues and patterns, and between patterns and mental models. Asks for a priority rule when the default resolution would be wrong.
• Leaves every assignment in pending_review status by default. You approve each one before it is considered committed.

Map is where opinions get recorded

Vision captures the idea. Extract commits the structure. Map is where opinion enters the pipeline.

The same entity with the same attributes can fit multiple patterns. An invoice can be a table (high cardinality, dense attributes), a list-detail (status lifecycle plus scan-and-drill), or a dashboard (if aggregated metrics matter more than individual rows). Which pattern is right depends on judgment about what the user is actually trying to do and what conventions they bring to the task.

Map is where you record that judgment as a rule. The rule travels with the project. When Claude Code generates the list page three weeks later, it does not re-decide. It reads the rule and applies it.

The recipe example

The Extract output for the recipe portion calculator produces this governance.

Visual cue assignments

• Recipe entity fires three cues: has_image (the photo attribute → card treatment with thumbnail); has_identity (the name attribute → primary label position, larger type weight); low_cardinality (cardinality many but in practice few saved recipes → simple list, no pagination needed).
• Ingredient entity fires currency_like_treatment for the quantity attribute (right-aligned, tabular numerals for scanability in the ingredient list).
• ScalingRatio entity fires no strong cues. It is a small attached record, not a first-class browsable object.

Pattern assignments

• "Home cook browses recipes" (Home Cook + Recipe + browse task) → card_grid. Rationale: image-heavy entity with moderate cardinality, browsing is scan-and-select. Alternative table rejected because the photo is the primary identity signal.
• "Home cook scales a recipe" (Home Cook + Recipe + scale task) → detail_page with an inline scaling control. Rationale: single-entity task, the scaling is the primary action, no reason to split into a separate wizard.
• "Home cook saves a ratio" (Home Cook + ScalingRatio + save inline in the scale task) → inline_edit. Rationale: low-complexity creation already in context of the recipe.

Mental models

• "Home cooks expect recipe apps to lead with the photo." Source: every recipe site and app they have used. Strength: strong. Implication: use the card grid with large thumbnails for the browse context; the photo is above the name in the detail view too.

Priority rules

• None required. The cues do not conflict with the patterns.

Every assignment is approved. The governance file is ready for Structure to read.

What Map is not for

• Page inventory. Map says what pattern a context uses. Structure says how many pages and where they sit in navigation.
• Region wireframes. Map says card_grid. Layout says how the card grid sits inside the shell and what the region around it contains.
• Copy or labels. Rationale fields describe the reasoning, not the product's language.
• Token values. The aesthetic direction and token source are a separate concern captured in Project Settings, not in the governance schema.

The discipline is that Map commits to the rules, not the arrangement. Every downstream layer reads the rules and applies them to its own arrangement.

Where to next

• Structure takes Map's pattern assignments and derives the page inventory.
• Extract is the input Map reads from.
• The governance schema for the full spec of Visual Cues, Pattern Matching, and Priority Assignment.