Know where truth lives—and who owns the result.

Approved documents define intended truth. The repository records implementation reality. Unity assets are organised by permanent module ownership and role; Slices describe temporary work owned by a module.

Documentation hierarchy

This model makes the current authority chain visible. Individual repositories may use an equivalent locked convention.

Project/
├── Idea/
│   └── Idea-Brief.md
├── Design/
│   └── Game-Design-Brief.md
├── Bible/
│   ├── Game-Identity/
│   ├── Player-Experience/
│   ├── Game-Structure/
│   ├── Core-Logic/
│   ├── Content/
│   ├── Design-Data/
│   ├── Progression-Economy/
│   ├── Presentation/
│   └── Reference/
├── Architecture/
│   ├── Architecture.md
│   └── Module-Map.md
└── Modules/
    └── Module-01/
        ├── Module-01.md
        └── Slices/
            ├── Slice-Map.md
            ├── Slice-01.md
            ├── Slice-02.md
            └── Slice-03.md

Authority lookup

QuestionAuthoritative source
What game are we making?Game Design Brief
What design truth is currently approved?Game Design Bible
What capabilities and boundaries exist?Architecture
Which Module owns a responsibility?Module Map
What must the Module provide?Module Requirements
What result is being implemented?Slice specification
What software exists now?Repository
Did the result satisfy the specification?Validation result

Permanent ownership and temporary work

Modules describe permanent ownership. Slices describe temporary development work.
Architecture

Module

Owns a stable capability, its state, contracts and behaviour throughout the project.

Delivery

Slice

Belongs to one owning module and specifies a testable result. It may integrate through approved contracts, but ownership remains explicit.

Every implementation asset is placed by asking: Which system owns it? Then: What role does it perform within that system?

Project → Module → Role → Optional Detail

Locked Unity project structure

Assets/
├── _Project/
│   ├── Application/
│   ├── Modules/
│   ├── Shared/
│   ├── Scenes/
│   ├── Settings/
│   └── Tests/
└── ThirdParty/
Application

Whole-application composition, startup and orchestration—not gameplay mechanics.

Modules

Permanent capability owners. Module-owned tests remain with their module.

Shared

Truly cross-cutting primitives with no natural module owner. Shared is not a dumping ground.

Scenes

Scene assets and composition roots; the final scene-root convention remains under validation.

Settings

Project-level configuration not owned by a single module.

Tests

Cross-module and whole-project tests.

ThirdParty

External packages remain visibly separate from project-owned work.

Standard internal Module structure

Modules/
└── ModuleName/
    ├── Runtime/
    │   ├── Components/
    │   ├── Logic/
    │   ├── State/
    │   ├── Contracts/
    │   ├── Events/
    │   └── Types/
    ├── Configuration/
    │   ├── Definitions/
    │   └── Assets/
    ├── Presentation/
    │   ├── Prefabs/
    │   ├── UI/
    │   ├── Animation/
    │   ├── Audio/
    │   └── VFX/
    ├── Editor/
    └── Tests/

Folders are optional vocabulary, not an empty-folder quota. Runtime owns executable behaviour; Configuration owns tunable data; Presentation owns visible and audible expression; Editor contains authoring support; Tests verify the module contract.

Asset Placement Explorer

Placement follows ownership, not where an asset happens to appear.

Recommended home

ChipDefinition

Assets/_Project/Modules/Chips/Configuration/Definitions/ChipDefinition.cs
Owner
Chips module
Why
Defines configurable chip data owned by the Chips capability.

Conventions still under validation

Scene roots: scene composition belongs under Scenes while domain behaviour stays in modules. The precise root/prefab convention is not locked.

UI safe area: safe-area adaptation should be reusable presentation behaviour with scene-level composition. Its final ownership boundary remains intentionally unsettled.