| 1 | --- |
| 2 | style_id: technical-deepdive |
| 3 | kind: style |
| 4 | summary: Mechanism-first technical explanation method that grounds every claim in constraints, trade-offs, and observable behavior. |
| 5 | keywords: [technical, architecture, engineering, mechanism, trade-off] |
| 6 | --- |
| 7 | |
| 8 | # Technical Deep Dive — Style Specification |
| 9 | |
| 10 | > Method and design defaults only. No project communication contract, brand identity, page structure, or SVG prototypes. |
| 11 | |
| 12 | ## I. Style Overview |
| 13 | |
| 14 | | Property | Value | |
| 15 | |---|---| |
| 16 | | Style Name | Technical Deep Dive | |
| 17 | | Best Fit | Architecture reviews, system explanations, engineering design docs, protocol and API walkthroughs, and technical postmortems | |
| 18 | | Reusable Intent | Make a technically literate audience understand how something actually works and why it was built that way, so they can evaluate, extend, or operate it | |
| 19 | | Sources | Authored in-repo as a bundled reference Style, 2026-08-07; distilled from engineering-explanation practice, not a single external document | |
| 20 | |
| 21 | ## II. Communication Method |
| 22 | |
| 23 | - **Preferred Mode**: instructional |
| 24 | - **Argument Flow**: Establish the problem and the constraints that make it hard, then the mechanism that resolves it, then the trade-offs that mechanism accepts, and finally what this means for building, operating, or migrating. Introduce a component only after the reader needs it; adapt depth to the audience's existing knowledge instead of replaying a fixed chapter order. |
| 25 | - **Page Message Discipline**: For every planned page, name the one mechanism, constraint, or behavior it explains, and state its consequence in the title or an equally dominant line. Keep a diagram and its explanation on the same page; never leave a diagram to speak alone or split one mechanism across pages that must be recalled together. |
| 26 | - **Claim Discipline**: Keep specification, current implementation, measurement, and design opinion distinct. Cite versions and configuration for behavior claims, attach conditions and workload to any number, and mark known-unknowns as open rather than smoothing them into confident description. Never present a planned or aspirational design as shipped behavior. |
| 27 | |
| 28 | ## III. Page Role Vocabulary |
| 29 | |
| 30 | | Role | Communication Job | Evidence Obligation | Composition Tendency | |
| 31 | |---|---|---|---| |
| 32 | | Problem and constraint | Establish what must be solved and what bounds the solution space | Name the real limits — load, latency, consistency, cost, compatibility, team — and their source | Make the binding constraint visually dominant over background context | |
| 33 | | System overview | Give a mental model of the whole before any part | Show only the components that carry the explanation, with honest boundaries | Establish a spatial arrangement that later pages reuse without redrawing | |
| 34 | | Mechanism walkthrough | Explain how the core behavior actually works | Follow one concrete path end to end; do not skip the step where the difficulty lives | Let the sequence drive the composition and keep each step's state legible | |
| 35 | | Data or control flow | Show what moves, in what order, and who decides | Distinguish request, data, and failure paths; label ordering and sync/async behavior | Keep the flow direction consistent and reserve emphasis for the decisive hop | |
| 36 | | Interface contract | Define what callers may rely on | State inputs, outputs, errors, idempotency, and versioning behavior that the source supports | Pair the contract with one realistic call or payload rather than exhaustive signatures | |
| 37 | | Trade-off comparison | Justify the chosen approach against real alternatives | Compare on axes that actually decided it; state what the choice gives up | Align alternatives on shared axes and mark the decision, not every difference | |
| 38 | | Failure mode | Explain how it breaks and what absorbs the break | Pair each failure with trigger, blast radius, detection, and recovery when known | Keep failure and response in direct visual correspondence | |
| 39 | | Measurement evidence | Ground performance or correctness claims | Give workload, environment, version, method, and variance; never a bare number | Let the measured relationship carry the page and annotate the decision-relevant point | |
| 40 | | Adoption or migration path | Translate the design into what a team does next | Connect steps to prerequisites, compatibility windows, and rollback | Make sequence and reversibility scannable without becoming a project calendar | |
| 41 | | Reference detail | Preserve depth needed to implement or audit | Retain exact names, parameters, defaults, and limits | Allow higher density while keeping structure and lookup path legible | |
| 42 | |
| 43 | ## IV. Evidence & Data Expression |
| 44 | |
| 45 | - **Argument Trace**: Every mechanism claim traces to an observable — a specification clause, a code path, a measurement, or a documented failure. Where the trace is missing, say the behavior is unverified instead of describing it with the same confidence as the verified parts. |
| 46 | - **Charts**: Choose the chart from the engineering question: distribution for latency, time series for behavior under change, comparison for alternatives. Show tails and percentiles rather than means alone, keep units and scale explicit, mark the threshold or budget that makes the number meaningful, and label log scales prominently. Never plot a projection and a measurement in the same series without distinguishing them. |
| 47 | - **Tables**: Use tables for contracts, configuration, capability matrices, and alternative comparisons. Keep one row shape per table, align units and defaults, mark required versus optional, and let empty mean "not applicable" only when the table says so. |
| 48 | - **Sources**: Attach version, commit, specification section, environment, or date to any behavior or number, close to the claim. Label estimates, projections, and vendor-reported figures as such. |
| 49 | - **Native Editability**: Prefer editable native charts and tables for benchmark data and contract matrices when the supported interface fits. Keep architecture and flow diagrams as editable shapes and text so reviewers can correct a box or an arrow; never flatten a diagram that the audience is expected to argue with. |
| 50 | |
| 51 | ## V. Visual System Defaults |
| 52 | |
| 53 | - **Preferred Visual Style**: blueprint |
| 54 | - **Composition**: Build the page around the structure being explained. Give the diagram the dominant region and keep its explanation adjacent rather than stacked below the fold. Preserve one spatial convention across the deck — flow direction, layer order, and component position — so a returning diagram is recognized instead of re-read. |
| 55 | - **Density**: Technical audiences tolerate density when it is organized. Allow detailed diagrams and dense reference tables under a consistent grid, but keep one idea per page and let boundary pages — problem statement, decision, conclusion — carry more whitespace. |
| 56 | - **Decoration**: Use precise lines, measured spacing, and functional annotation. Line weight, dash pattern, and arrowhead carry meaning and stay consistent once assigned. Avoid gradient-filled server icons, drop-shadowed boxes, glow, and decorative isometric scenery that adds no structural information. |
| 57 | - **Color Behavior**: Start from a restrained technical field and let color encode a declared dimension — layer, ownership, path type, or state. Fix that mapping across the deck and keep it visible where it is used. Reserve saturated accent for the component under discussion; never color components decoratively when the same palette elsewhere carries meaning. Any confirmed Brand or Deck identity replaces these tendencies. |
| 58 | - **Typography Character**: Use a clear technical sans-serif hierarchy with a genuinely monospaced companion for identifiers, paths, payloads, and commands. Keep code-like text unwrapped and legible at slide size, distinguish it from prose without decorative containers, and derive hierarchy from weight and spacing. Exact families remain current-project or resolved identity decisions. |
| 59 | |
| 60 | ### Fallback Color Scheme |
| 61 | |
| 62 | | Role | HEX | Purpose | |
| 63 | |---|---|---| |
| 64 | | Field | #0F1C2B | Deep technical ground for schematic pages | |
| 65 | | Surface | #16283C | Raised region for grouped components | |
| 66 | | Ink | #E6EDF5 | Primary text and diagram labels | |
| 67 | | Structure | #4A7BA7 | Component outlines, connectors, and grid | |
| 68 | | Focus | #4FC9E8 | The component, path, or value under discussion | |
| 69 | | Caution | #E8A54F | Failure paths, limits, and warnings | |
| 70 | |
| 71 | ## VI. Image & Icon Direction |
| 72 | |
| 73 | - **Preferred Image Rendering**: 3d-isometric |
| 74 | - **Image Usage**: Use imagery only where spatial or physical reality aids understanding — topology, hardware, deployment geography, or a real screen. Keep architecture, sequence, and state diagrams as authored vector structure; never replace an explanatory diagram with a stock illustration of one. |
| 75 | - **Image Treatment**: Crop screenshots to the region that carries the point and keep their text readable at slide size, magnifying a detail rather than shrinking the whole frame. Keep any embedded interface legible and unretouched, and caption what the reader should notice. Avoid full-bleed atmospheric technology imagery and synthetic text inside generated images. |
| 76 | - **Icon Treatment**: Use one coherent icon family at consistent weight, and only to identify a recurring component class or state. Keep an icon's meaning fixed once assigned. Avoid vendor logos as generic component symbols, mixed icon languages inside one diagram, and icon grids that decorate a page without labeling anything. |
| 77 | |
| 78 | ## VII. Review Focus |
| 79 | <!-- visual-review-trigger: explicit-user-only --> |
| 80 | > Apply this section only after the user explicitly activates visual review. It never triggers that stage. |
| 81 | |
| 82 | - The mechanism each page explains is identifiable at the rendered slide size, not only from the narration. |
| 83 | - Diagram labels, identifiers, code-like text, and axis units remain legible at the rendered slide size. |
| 84 | - Flow direction, layer order, and component position stay consistent wherever a diagram recurs. |
| 85 | - Any color, line weight, or dash pattern that encodes meaning is used consistently and is decodable on the page where it appears. |
| 86 | - Numbers carry their conditions; measurement and projection remain visually distinguishable. |
| 87 | - Dense reference pages retain one scan path and do not hide overflow or truncated identifiers. |
| 88 | - No unverified or planned behavior is presented with the same confidence as observed behavior. |
| 89 |