# Information Architecture

Information architecture defines what exists, how it is named, where it is found, and which relationships users must understand. Organize around user tasks and domain objects rather than implementation folders.

[Kit README](README.md) · [Project Overview](Project%20Overview.md) · [PRD](Full%20PRD%20Template.md) · [Master Build Prompt](Master%20Build%20Prompt.md) · [Completion Checklist](Project%20Completion%20Checklist.md)

## Content and Object Inventory

| Object | Purpose | User Actions and Permissions | Lifecycle |
| --- | --- | --- | --- |
| Page | identity or ownership | [VIEW/CREATE/EDIT/DELETE BY ROLE] | [RETENTION] |
| NavigationItem | core workflow | [VIEW/CREATE/EDIT/DELETE BY ROLE] | [RETENTION] |
| ContentEntry | core workflow | [VIEW/CREATE/EDIT/DELETE BY ROLE] | [RETENTION] |
| ContactSubmission | supporting state | [VIEW/CREATE/EDIT/DELETE BY ROLE] | [RETENTION] |
| Asset | supporting state | [VIEW/CREATE/EDIT/DELETE BY ROLE] | [RETENTION] |
| Redirect | supporting state | [VIEW/CREATE/EDIT/DELETE BY ROLE] | [RETENTION] |

## Proposed Navigation

| Level | Area | User Question It Answers | Visibility Rule |
| --- | --- | --- | --- |
| Primary | [CORE WORKSPACE] | Where do I perform the main task? | [ROLES] |
| Primary | [HISTORY OR LIBRARY] | What already exists? | [ROLES] |
| Secondary | [SETTINGS] | How do I control preferences and data? | Authenticated user |
| Contextual | [DETAIL/ACTION] | What can I do with this item? | Object permission |
| Operational | [ADMIN/REVIEW] | What requires oversight? | Authorized operators only |

For a website project, make the domain vocabulary explicit: Page, NavigationItem, ContentEntry, ContactSubmission, Asset, Redirect. Choose one canonical name for each object and use it in headings, URLs, database records, events, and support text.

## Sitemap or Surface Map

~~~text
[ENTRY]
├── [PRIMARY AREA]
│   ├── [LIST OR START STATE]
│   └── [DETAIL / CORE ACTION]
├── [HISTORY / SAVED WORK]
├── [HELP / GUIDANCE]
└── [ACCOUNT / SETTINGS]
    ├── [PREFERENCES]
    └── [PRIVACY / ACCESS]
~~~

Adapt this map to the actual platform. A command-line API may use documentation sections instead of screens; a game may use menus, levels, and HUD states; an automation may use workflow and run views.

## Naming and Findability Test

1. Give five users cards containing the proposed labels.
2. Ask them to group related cards and name each group.
3. Ask where they would look for three high-value tasks.
4. Rename ambiguous sections using user language, then repeat.

## Completion Criteria

- [ ] Every top-level area supports a real user task.
- [ ] Every domain object has one canonical name.
- [ ] No sensitive or role-restricted area relies only on hidden navigation for protection.
- [ ] Empty, archived, deleted, and unavailable states have a defined location or behavior.
- [ ] Primary content is reachable in two navigation decisions where practical.
- [ ] The map agrees with user flows, data entities, URLs, and permissions.