# SiXiS Dashboard — Writing Style Guide **Status:** Active. Applies to all substrate writing in this project. **Established:** 2026-05-05 after Tommy flagged that protocol-jargon descriptions were hard to consume. **Scope:** Event descriptions, poll questions, convergence summaries, forced-rule descriptions, change-log titles, project descriptions, and any other text that lands in the substrate or on the dashboard. --- ## The Voice **Conversational, plain English, like talking to a colleague.** Write the way you'd explain what happened to a smart human who isn't steeped in protocol jargon. The dashboard is a daily-driver tool for Tommy — and a public surface at dashboard.sixis.ai — not a database admin interface. ### Person and tone - **Second person ("you")** for sovereign actions, decisions, overrides, ratifications. *"You stepped in and directed cross-poll over menu-asking."* - **First person ("I")** for orchestrator self-reflection — admitting breakdowns, narrating what I did, owning mistakes. *"I dumped a long YAML schema at you instead of explaining things conversationally."* - **Third person** for brain actions and external facts. *"GPT adopted Deepseek's position with a re-audit reason."* - Never write about Tommy in the third person inside event descriptions ("Tommy did X"). Address him directly with "you". ### Sentence shape - Real sentences with subject, verb, object. - One idea per sentence when possible. - Don't open with stenographic headers like "Z1+Z2:" or "Q1 storage:". Open with the actual question or statement. - Lead with what happened or what's needed, not with the protocol-machinery framing. --- ## What to keep technical These references stay verbatim because the dashboard linkifies them with hover tooltips: - `FORCED_RULE_03`, `FORCED_RULE_10`, etc. — write the underscore form, not "forced rule 3" - `K1` through `K7` — Kernel Principles, standalone capital-K-digit - `M-Imperative-3` — hyphenated form - Event types in technical contexts (`cross_poll`, `convergence`, etc.) when referencing the schema These remain because they carry precise meaning and Tommy can hover for full descriptions. --- ## Length - **Event descriptions:** 1–3 sentences typical. Up to ~400 chars for ones that narrate a complex moment. - **Poll questions:** 1 question, asked plainly. Avoid compound questions stacked with slashes. - **Convergence summaries:** 2–4 sentences narrating who diverged, what got resolved, what came out of it. - **Rule descriptions:** As long as needed to be useful, but lead with the rule in plain language before any procedural detail. --- ## What NOT to write - ❌ "Orchestrator dumped full Layer B YAML inline to user-facing output instead of conversational synthesis. K1 cognitive load violation." - Third-person procedural, no "you," reads like a postmortem from a database. - ✅ "I dumped a long Layer B YAML schema inline at you instead of explaining things conversationally. You called it out as a K1 violation — not a personal preference but a protocol rule. This became FORCED_RULE_10." - ❌ "Z1+Z2: PROJECT_TYPE / TIER / ARCHETYPE / SCOPE for the dashboard build" - Header-style stenography, no real question. - ✅ "What kind of project is the dashboard build, what risk tier, and how should we structure the work?" - ❌ "Substrate not capturing its own building activity — UI iterations and frictions happening in chat without substrate logging. Meta-loop gap caught." - Telegraphic, no agent doing anything. - ✅ "The substrate wasn't capturing its own building activity. UI iterations and frictions were happening in chat without being logged as substrate events. You caught this with: 'I'm not seeing these activities being logged into the event'." --- ## Where this applies (and where it doesn't) **Applies to:** - All `events.description` written via `sixis suggest-accept`, `sixis event-log`, `sixis poll-start`, `sixis converge`, `sixis project-start` - All `polls.question` and `polls.convergence_summary` - All `forced_rules.description` (when adding new rules, new content should be conversational; existing rules from Layer B markdown are grandfathered) - `changes.title` (commit messages already tend to be readable; just keep them so) - Project descriptions **Does NOT apply to:** - The Universal Shell / SiXiS Protocol document itself — that's a formal spec - Migration SQL files — those are technical artifacts - The CLI's internal audit log entries — those are debug-style - Code comments and docstrings in `sixis.py` — those are code-style, separate concern --- ## How to enforce going forward 1. **Read this file** at the start of any session that involves writing substrate content. 2. **Auto-memory entry** (`feedback_substrate_voice.md`) carries a short version of this rule into every Claude session, so the rule is loaded even before any project file is read. 3. **`FORCED_RULE_12`** in the project's substrate makes the rule queryable on the dashboard itself ("Rules in Play" panel). 4. **Future amendments** to this guide go via the standard `[AMENDMENT]` procedure on Layer B. --- ## Why this exists Without a captured guideline, every future session has to re-learn this through Tommy's correction. That's a meta-loop tax the substrate exists to eliminate. This file is the persistence layer for *how to write* — same way the substrate is the persistence layer for *what happened*.