← Market Analyst · c12

session-decisions-handoff.md

Product-session decisions on the cycle pages: what the content is for

Contents
  1. Where the content is
  2. The shape of each subsection
  3. What a reader should come away with
  4. The design story across the four cycles
  5. Known gaps in the content

A hand-off note for whoever redesigns the design site's cycle pages. Written 2026-10-26 with the first pass of the content. This note covers the information, its intent and the story it tells. The receptacle, meaning layout, components and navigation, is yours to design.

Where the content is

A ### Product-session decisions subsection under ## Outcome in four design cycles:

CycleIts slice of the story
c114.governance-phase2The object model this cycle formed, and what the sessions did to each of its rulings (D0–D9). The cycle is still open, so this is the model's movement, not the cycle's result.
c116.policy-changesetsA pull-request publishing proposal that the sessions overtook within hours, and which parts survived. CYCLE.md written after the fact.
c118.policy-structure-and-publishingThe Oct 19 collapse drawn in the lab, Mark's Wednesday-morning walk, and which of those rulings that afternoon's session overturned. CYCLE.md written after the fact.
c121.governance-v1-scopeThe Oct 21 rulings built, the Oct 23 review of the build, and what Oct 23 sent forward.

The sessions are Rob's Mon/Wed/Fri "Qpoint Product" meetings: Mark Parson, Mark Peterson (advisor), Rob Genova, Tyler Flint. Their transcripts and extracted session records live in market-analyst: data/raw/<id>.txt and data/processed/<id>.json → session.decisions / todos / ideas.

The shape of each subsection

The markdown is regular enough to parse:

  1. A provenance line in italics: who was in the room, the call ids and dates, the status words, and "a later session wins".
  2. The story. One short paragraph: what this cycle's slice of the decisions means.
  3. Groups, each a bold line, then a list. The group names vary by cycle: "Ruled …, built here", "Confirmed …", "Sent forward", "Superseded …", "This cycle's rulings, and what became of them".
  4. Entries, one per decision:
    • Bold: the decision, stated as the rule rather than the discussion.
    • The session date(s) and, where it matters, whose words.
    • The status, in italics: Ruled, Direction, Open, Idea or Superseded.
    • → where it landed: cycle, decision id (D4, W.8, L5) or lab page.

The status words match the planned decisions ledger in product-input-plan.md §D: ruled / direction / open / tabled / superseded / rejected. If data/decisions.json is built, these entries are its seed data, and the pages could read the ledger instead of the markdown.

What a reader should come away with

Each of these intents depends on being able to see the one before it:

  1. Where a decision came from. It came from a conversation, on a date, with named people. Every one of these rulings is team and advisor judgement; none is customer evidence. The provenance line exists so that difference stays visible.
  2. How settled it is. Ruled, direction, open or idea. Direction items are drawn as options; ruled items are drawn as the one model.
  3. Where it landed. Which cycle built it, under which decision id, on which lab page. This is what connects a conversation to an artifact.
  4. What became of it. A decision can be superseded, sometimes within hours. The point of keeping superseded entries is that nobody revives a dropped idea from an old transcript or mock. The "do not revive" lists matter as much as the rulings.
  5. What's next. Items sent forward are the next cycle's inputs.

The design story across the four cycles

Two weeks in which the governance model got smaller by subtraction, and the lab kept pace:

  • Oct 9, c114. Fourteen intents are read as one object model: Policy, Scope, Policy Group, Exception, Enforcement per policy × scope, Finding with Ignore and Block.
  • Oct 12 and Oct 14, sessions. Resolving a finding is separated from preventing recurrence. Policy groups are mapped to teams. Changes are staged and deployed, never live toggles.
  • Oct 19, the session the model collapsed in. One policy per concern. Mode on the policy. Exceptions are the only nuance. Groups are derived. Ignore and Block leave the finding. Publishing is a separate act, one locked draft.
    • The same morning, c116 had proposed personal named changesets with approval.
    • → c118 drew all of it in the lab within a day.
  • Oct 21 morning. Mark rules W.1–W.10 alone on the review walk: several server drafts, approve and promote; a required by-when on loosening.
  • Oct 21 afternoon, session. It subtracts again. Snooze becomes a mode with an optional Until. The required by-when goes. One shared draft, no approval. "Policy Config" is one versioned file. Propagation is per version. Change impact is shown before a change is made. The simulator goes.
  • Oct 23, c121. Builds the result from four sources. That afternoon's session reviews it ("we're not looking at Illustrator right now") and moves to the next layer: what's inside a policy (explicit rules plus implicit intent questions), control vs policy, frameworks.
  • Oct 26, today's session. Frameworks.

Two shapes in this story are worth showing, whatever the receptacle:

  • Supersession chains. One draft (Oct 19) → several drafts with approval (Oct 21 morning) → one shared draft, no approval (Oct 21 afternoon). Snooze (Oct 19) → mode + Until (Oct 21). The chain shows how the team decides.
  • Conversation → lab → review. A ruling is drawn in the lab, the lab is shown at the next session, and the session rules on what it sees. The cycle pages are where that loop is visible.

Known gaps in the content

  • Today's session (2026-10-26, frameworks) is not yet fetched.
  • The Oct 12 and 14 entries come from the extracted session records and the Oct 19 brief, not a fresh read of those transcripts.
  • c114's object-model.md still describes the 2026-10-09 model. The decisions sections say so, but the model document itself is out of date.

Qpoint Brand Style Guide