Why a database instead of a single doc?

A doc cannot be queried, filtered, or rolled up. A database can. The whole point of putting a brief in Notion is to make every downstream artifact discoverable from the brief and the brief discoverable from every artifact. Single-document briefs lose that traceability the moment a second brief exists. The database scales; the doc does not.

What property types are doing the work?

Select properties for the four axis positions, since Select is queryable and forces a single value. Relation properties connecting downstream artifact databases (Pages, Components, Articles, Releases) back to the brief. Rollup properties aggregating from related rows so a brief page shows counts of artifacts that reference it. Status property for direction-status review. Title, URL, Date, and Person are the standard support cast.

How does the team avoid the Notion-as-CMS habit overriding the spec patterns?

Two ways. First, briefs go in their own database, not a generic Pages database, so the schema is tight and the views are purpose-built. Second, downstream artifact databases use a Relation back to the Briefs database as a required property; without that relation the artifact does not show up in any brief view. The schema enforces traceability that ad-hoc page hierarchy cannot.

Integration · Notion

RampStack skills in Notion.

Briefs as database rows. Axes as Select properties. Relations and Rollups doing the traceability work that ad-hoc pages cannot.

Notion gives the team databases, properties, relations, rollups, views, and templates. The integration uses each one for its load-bearing role. Briefs live in a Briefs database. The four axes are Select properties on each row. Downstream artifact databases use Relation properties back to the brief, so the brief page rolls up every artifact that references it. Views slice the workspace by axis position across artifact types. The schema does the work that documentation alone cannot.

The shape

Brief into Notion primitives.

The Briefs database holds one row per brief. Artifact databases (Pages, Components, Articles, Releases) each have a Relation property pointing back to a brief row. The brief row uses a Rollup to count related artifacts. Views on each artifact database filter by the brief or by axis label.

The Briefs database is the canonical source. Each artifact database relates back. Rollups count artifact coverage per brief. Views slice by axis.

The mapping

Brief artifacts to Notion primitives.

Brief artifact	Notion primitive	Notes
Brief project name	Title property of the row	Database titled “Briefs”
Synthesis paragraph	First heading inside the row page	Page body, not a property
Tone axis position	Select property: Tone	Options: Professional, Conversational, Playful, Provocative
Aesthetic axis position	Select property: Aesthetic	Editorial Restrained, Polished Standard, Controlled Maximalist, Expressive Maximalist
Relationship axis position	Select property: Relationship	Authority, Peer, Companion, Coach
Sensory axis position	Select property: Sensory	Functional, Considered, Resonant
Rejection list	Toggle block: Won't do	Inside the row page body
Inspiration references	Bookmark blocks under an Inspiration heading	Page body
Linked artifacts	Relation property to artifact databases	Bidirectional, one Relation per artifact db
Artifact coverage count	Rollup property on the brief row	Count, by Relation

Select beats Multi-select for axis positions. The brief picks one position per axis; the moment Multi-select allows two, the brief stops being directional. Views and filters also handle Select cleanly and degrade messily with multi-select.

The Relation property is the load-bearing piece. Without it, every artifact is a doc the brief cannot reach. Configure the Relation as bidirectional so the artifact page shows the brief it serves, and the brief page shows the artifact in a related-rows section.

Templates

Copy these into the workspace.

Briefs database schema

Create a database titled Briefs. Configure these properties in order. Every brief in the workspace becomes one row.

Database: Briefs

Property                Type           Configuration
--------                ----           -------------
Name                    Title          required
Status                  Status         Draft / Active / Archived
Owner                   Person         single
Created                 Created time   auto
Last edited             Last edited    auto

Tone                    Select         Professional / Conversational
                                       / Playful / Provocative
Aesthetic               Select         Editorial Restrained /
                                       Polished Standard /
                                       Controlled Maximalist /
                                       Expressive Maximalist
Relationship            Select         Authority / Peer /
                                       Companion / Coach
Sensory                 Select         Functional / Considered /
                                       Resonant

Pages                   Relation       -> Pages database
Components              Relation       -> Components database
Articles                Relation       -> Articles database
Releases                Relation       -> Releases database

Pages count             Rollup         Pages, count all
Components count        Rollup         Components, count all
Articles count          Rollup         Articles, count all
Releases count          Rollup         Releases, count all

Coverage                Formula        prop("Pages count") +
                                       prop("Components count") +
                                       prop("Articles count") +
                                       prop("Releases count")

Brief page template (database template)

Save this as a database template on the Briefs database. New briefs created from the template start with the right structure.

# Synthesis

[One paragraph in present tense describing what
this combination produces in practice.]

# Rationale per axis

- Tone: chose [position] because [one sentence]
- Aesthetic: chose [position] because [one sentence]
- Relationship: chose [position] because [one sentence]
- Sensory: chose [position] because [one sentence]

# Won't do (toggle)

> Click to expand. The rejection list is the most
> useful part of the brief.

  - [specific phrasing, structure, or visual move
    this brief excludes]
  - [next item]
  - [next item]

# Inspiration

(Use bookmark blocks for each reference.)

[bookmark URL]
[bookmark URL]
[bookmark URL]

# Open questions

- [anything still unresolved that downstream
  artifacts will need answered]

Artifact database property pattern

Apply this property pattern to every artifact database (Pages, Components, Articles, Releases). The Brief Relation is what makes the rollup possible.

Database: Pages (or Components, Articles, Releases)

Property                Type           Configuration
--------                ----           -------------
Name                    Title          required
Status                  Status         Drafting / In review /
                                       Published / Archived
Owner                   Person         single
URL                     URL            optional, for
                                       deployed artifacts

Brief                   Relation       -> Briefs database
                                       (required during refinement)

Tone (from brief)       Rollup         from Brief, Tone Select,
                                       show original
Aesthetic (from brief)  Rollup         from Brief, Aesthetic
Relationship (from brief) Rollup       from Brief, Relationship
Sensory (from brief)    Rollup         from Brief, Sensory

Direction status        Status         Aligned / Drift / Needs review
Last reviewed           Date           manual, set during direction
                                       review

Linked database views to build

Create these as linked database views on the team dashboard. Each surfaces a different cut of the workspace.

View 1: Briefs by Status (board)
  Source: Briefs database
  Layout: Board
  Group by: Status
  Visible properties: Name, Tone, Aesthetic, Coverage

View 2: Active briefs and their coverage (table)
  Source: Briefs database
  Filter: Status = Active
  Sort: Coverage descending
  Visible properties: Name, Tone, Aesthetic,
                      Relationship, Sensory,
                      Coverage, Owner

View 3: All artifacts under one brief
  Source: Pages database (and the others, separately)
  Filter: Brief = [select the brief from the dropdown]
  Group by: Status

View 4: Drift surface
  Source: Pages database (etc.)
  Filter: Direction status = Drift
  Sort: Last reviewed ascending
  Visible properties: Name, Owner, Last reviewed

Voice guide that references the brief

The team's voice guide lives in a Notion page with linked-database sections. It pulls voice examples from artifact databases filtered by tone Select on the brief. The page reads as a voice doc; the data underneath stays queryable.

# Voice guide

This guide lives downstream of the brief. The four
voice attributes below derive from the Tone position
selected on the active brief. To change them, change
the brief.

## Voice attributes

We are [direct], not blunt.
We are [warm], not saccharine.
We are [confident], not arrogant.

(These three lines come from the brief synthesis.
Update them when the brief changes.)

## Examples

### Headlines we use (linked database)

Source: Articles database
Filter: Tone (from brief) = [the active brief's tone]
        AND Status = Published
Group by: Brief

### Empty-state copy we use (linked database)

Source: Components database
Filter: Tone (from brief) = [the active brief's tone]
        AND Name contains "empty"
Group by: Brief

Failure modes

Where the Notion integration goes wrong.

The brief lives as a stand-alone page. Without the Briefs database, the Select properties are not available, no Relation can point at the brief, and no Rollup can aggregate against it. The brief becomes a doc that only full-text search reaches. Move briefs into a database before any other pattern matters.

Artifacts created without the Brief Relation. Someone drops a quick page into the Pages database without setting Brief, and the artifact disappears from every brief view. Make Brief a required property on the artifact database (Notion supports required properties on database creation forms via templates). Add a hygiene view that surfaces orphaned artifacts.

Multiple briefs without distinguishing properties. The team accumulates ten briefs all titled with the project name, all at Status = Active, no Owner. The workspace cannot tell which brief is current for which surface. Keep Status disciplined (one Active per surface), require Owner, and use a Multi-select Surface property if multiple briefs cover different surfaces of the same product.

Notion-as-CMS habits override Notion-as-spec patterns. The team treats the brief like a published page (lots of formatting, hero image, embedded video) rather than a structured row. The result is briefs that look great and aggregate poorly. Keep the brief schema-first; the prose lives inside the page body, but the queryable data lives in properties.

Composition

Which skills feed the Notion integration.

The brief comes from creative-direction. Voice docs derived from a brief consume brand-voice. Visual standards consume brand-identity. Each downstream skill produces an artifact that lands in one of the artifact databases with a Relation back to the brief, so the workspace stays traceable.

Continue reading.

For Notion platform mechanics (database property types, Relation and Rollup configuration, linked database views, database templates), Notion's help center is the source of truth. Every primitive used above is available on Notion's Plus plan and higher.

Frequently asked questions.

Why a database instead of a single doc?: A doc cannot be queried, filtered, or rolled up. A database can. The whole point of putting a brief in Notion is to make every downstream artifact discoverable from the brief and the brief discoverable from every artifact. Single-document briefs lose that traceability the moment a second brief exists. The database scales; the doc does not.
What property types are doing the work?: Select properties for the four axis positions, since Select is queryable and forces a single value. Relation properties connecting downstream artifact databases (Pages, Components, Articles, Releases) back to the brief. Rollup properties aggregating from related rows so a brief page shows counts of artifacts that reference it. Status property for direction-status review. Title, URL, Date, and Person are the standard support cast.
How does the team avoid the Notion-as-CMS habit overriding the spec patterns?: Two ways. First, briefs go in their own database, not a generic Pages database, so the schema is tight and the views are purpose-built. Second, downstream artifact databases use a Relation back to the Briefs database as a required property; without that relation the artifact does not show up in any brief view. The schema enforces traceability that ad-hoc page hierarchy cannot.
What is the most common Notion-specific failure of this integration?: The brief lives as a stand-alone page instead of a database row. Without the database structure, the Select properties are not available, no Relation can point at it, and no Rollup can aggregate against it. The brief becomes another doc in the workspace, queryable only by full-text search. The first migration step every team needs is converting the brief from page-with-text to row-in-database.