Skip to content
chiltepin

Every typed block

Every block type in chiltepin-core, with its starter template rendered right here by the real pipeline — the same parse → validate → render path chiltepin build uses.

Showing 107 of 107

Document cover

Document cover — title, subtitle, tag, and an optional logo.

title: New document
subtitle: One-line description.
tag: DRAFT
Narrative & proseDocs →

Callout

A single aside — note, tip, warning, or danger.

SECTION 01 · Note

Heads up

Note
A short note that the reader should not miss.
Narrative & proseDocs →

Structured prose

Structured prose (headings, paragraphs, lists, quotes) as data.

SECTION 01 · Overview

Overview

Background

A paragraph explaining the context.

  • Idea one
  • Idea two
  • Idea three
Narrative & proseDocs →

Glossary

Term → definition rows.

SECTION 01 · Glossary
Idempotency
Doing a thing twice has the same effect as doing it once.
SLO
Service-level objective the team commits to.
Narrative & proseDocs →

Pull quote

A standout pull-quote with optional attribution.

SECTION 01 · Quote

The whole design in one sentence.

The takeaway
Narrative & proseDocs →

Layered explanation

N numbered layers, each answering one question (L1 / L2 / L3).

SECTION 01 · Layers

The model in three layers

1
L1
Identity
JWT
Are you signed in?
Validate the token and resolve the user.
2
L2
Scope
Lookup
Which sites?
Confirm the request is in range.
3
L3
Permission
App DB
May you do this?
Check the action against the matrix.
Narrative & proseDocs →

Figure

An image with a caption in a bordered card (optional pixel width cap).

src: https://example.com/architecture.png
alt: The deployment topology
caption: "The production topology: CDN, gateway, and two service tiers."
width: 560
Narrative & proseDocs →

FAQ

Q&A accordions — native details/summary, no JavaScript.

SECTION 01 · FAQ

Common questions

Where does the content live?

In the .md files on disk — they are the single source of truth.

Do diagrams need a drawing tool?

No. Diagrams are typed YAML blocks; the renderer draws the SVG.

How do I validate a doc?

Run chiltepin check and fix every diagnostic it reports.

Narrative & proseDocs →

Section divider

A full-width section break — kicker, display title, optional subtitle on an accent-washed band; a clean interstitial slide in decks.

SECTION 01 · Divider
PART 2
What we change

The three fixes, in the order we ship them.

Narrative & proseDocs →

Big number

One hero metric at presentation scale — a display-size value with an optional delta + trend arrow, a one-line claim, and a context line.

SECTION 01 · Big number
-75%-1.8s
Checkout p95 after moving capture off the request path

2.4s → 600ms, measured over four weeks of production traffic

Narrative & proseDocs →

Takeaways

The 2-6 things to remember — numbered rows at presentation scale, each a bold one-liner with an optional detail; a deck’s closing slide.

SECTION 01 · Takeaways
Takeaways
  1. The synchronous capture call was the bottleneck

    It accounted for 71% of the 2.4s checkout p95.

  2. Moving it to a queue cut p95 by 75%
  3. Conversion recovered within two weeks

    +0.4pp against the pre-regression baseline.

Narrative & proseDocs →

Table

Genuinely tabular data; cells can carry a tone.

SECTION 01 · Comparison
FieldDescription
nameDisplay name
idStable identifier
Tables & codeDocs →

KPI cards

KPI cards with a delta and an up / down / flat trend.

SECTION 01 · Metrics

This quarter

12.4k
Active users
▲ +18%
99.95%
Uptime
— 0
142ms
p95 latency
▲ -22ms
Tables & codeDocs →

Code snippets

Code the reader will copy or diff: highlighted snippets with `highlight` line ranges, `lines` numbers, and a `cols` grid; `kind: compare` sets before / after side by side, `kind: diff` a unified diff, `kind: terminal` a shell session.

also: diff, terminal

SECTION 01 · Code
add.tsTypeScript
export function add(a: number, b: number): number {
  return a + b;
}
add.test.ts
expect(add(2, 2)).toBe(4);
Tables & codeDocs →

SLOs & error budgets

Service-level objectives — SLI, target vs current, and an error-budget burn bar.

SECTION 01 · Service objectives

Orders API — objectives

Availability30d

Successful requests / total requests

Target99.9%
Current99.97%
25% of error budget used
Latency30d

Requests served under 400 ms (p99)

Target99%
Current98.9%
70% of error budget used
Tables & codeDocs →

Benchmark table

Measured results side by side — subject columns (one can be outlined as the focus) × metric rows, best in each row derived and highlighted, several conditions per row supported.

SECTION 01 · Benchmark

Retrieval engines, measured

BenchmarkOursv2.1Vendor AVendor B
Answer accuracyinternal QA set
82.4%
79.1%
74.8%
p95 latency500 rps soak
310 ms
420 ms
290 ms
Cost per 1k queries
$0.14cached
$0.90cold
$0.21cached
$1.10cold
$0.18cached

Single region, same corpus, October run.

Tables & codeDocs →

API

3 blocks

API endpoint

A Swagger-style API endpoint card.

SECTION 01 · API endpoint

Create an order

POST/ordersBearer token

Submit a cart and create a new order.

Parameters
NameInTypeDescription
idempotency-keyheaderstringSafe-retry key
Request body
FieldTypeDescription
items requiredItem[]Line items
couponstringOptional discount code
Responses
StatusDescription
201Order created
400Invalid cart
401Missing or invalid token
Example request
{ "items": [{ "sku": "A1", "qty": 2 }] }
Example response
{ "id": "ord_123", "status": "pending" }
APIDocs →

Packet layout

A wire format laid out bit by bit — fields wrap across rows of `width` bits, the way an RFC header diagram reads.

SECTION 01 · Wire format

Request header

PACKET
Packet layout081624Version14Version — 4 bits at offset 0Flags4Flags — 4 bits at offset 4Length24Length — 24 bits at offset 8Request id32Request id — 32 bits at offset 32032

64 bits · 8 bytes

APIDocs →

Event contract

An async event contract card — name, channel, producers → consumers, delivery guarantees, and the payload fields with the partition key marked; the twin of endpoint.

SECTION 01 · Event contract
EVENT·v2order.placedchannelorders

A customer completed checkout and the order is accepted.

Producers (1)
checkout
Consumers (3)
billingfulfilmentanalytics
deliveryat-least-onceorderingper-keykeyorder_idretention7d
Payload
FieldTypeDescription
#order_iduuidThe order this event is about
customer_iduuidThe buyer
totalmoneyGrand total after discounts
?couponstringDiscount code applied, if any
# partition key · ? optional
Headers
FieldTypeDescription
trace_idstringW3C trace id
Example
{ "order_id": "ord_123", "customer_id": "cus_9", "total": "42.00 EUR" }
Errors
ErrorWhen
DuplicateOrderthe same order_id was already processed

Consumers must be idempotent on order_id.

APIDocs →

Architecture

9 blocks

C4 architecture

C4 model — context / container / component.

SECTION 01 · C4 model

System context

C4 · CONTEXT
C4 diagram: 3 elements, 2 relationshipsPERSONShopperA customer placing an order.SYSTEMShopCoThe retail platform.EXTPayment GWStripe authorisation.places orderauthorises
LegendPERSONpersonSYSTEMsoftware systemEXTexternal systemoutside the boundaryusesthe system in scope
ArchitectureDocs →

UML class diagram

A class diagram — attributes, methods, UML relationships.

SECTION 01 · Class model

Class model

UML
UML class diagramOrderid: UUIDstatus: Statustotal: Moneyplace()cancel()OrderItemid: UUIDsku: Stringqty: int«enumeration»StatusPENDINGCONFIRMEDCANCELLEDhas
Legendassociationcomposed of
ArchitectureDocs →

Component tree

A top-down component tree (root / layout / page / hook / store).

SECTION 01 · Component tree

React component tree

FE
Component treeROOTAppLAYOUTLayoutPAGEHomePAGEOrdersOrderCardHOOKuseOrderSTOREcartZustand
LegendcomponentROOTrootLAYOUTlayoutPAGEpageHOOKhookSTOREstore / stateleaf / storetree root
ArchitectureDocs →

Cluster topology

Kubernetes-style namespaces holding services, with replicas.

SECTION 01 · Cluster

Production cluster

CLUSTER
Cluster diagramapi namespacenamespacedata namespacenamespacewebNext.jsSVC×3ordersGoSVC×4postgresPostgres 16DB×1redisRedis 7CACHE×2
LegendSVCserviceDBdatabaseCACHEcachecalls
ArchitectureDocs →

Block diagram

Generic boxes-and-arrows architecture (grid or layered bands); `preset: infra | event | ddd | network` picks the domain styling.

also: infra, event, ddd, network

SECTION 01 · Architecture

System architecture

ARCH
Block diagram: 6 nodes, 5 connectionsServicesEdgeCDNCloudflareEDGEGatewayEnvoyGATEWAYAPIGoSVCWorkerGoSVCPostgres16DBEventsNATSQUEUE
LegendEDGEedge / CDNGATEWAYgatewaySVCserviceDBdatabaseQUEUEqueuecallsasync / optionalentry point
ArchitectureDocs →

Frontend logic graph

Frontend module graph — components, hooks, interfaces, strategies; `variant: be` renders the backend flavour (controller / service / repository).

also: belogic

SECTION 01 · Frontend logic

Frontend modules

LOGIC
Module graphHOOKuseOrdersSERVICEordersServiceINTERFACEOrdersClientSTRATEGYHttpOrdersClientOrders APIEXTHTTPS
LegendHOOKhookSERVICEservice / use caseINTERFACEinterfaceSTRATEGYstrategyEXTexternalcontract / externalusesimplementsnetwork call
ArchitectureDocs →

Capability map

A target-architecture capability map — tinted domain areas packed with small status-coded capability tiles (current / target / new / gap / deprecated).

SECTION 01 · Architecture map

Target platform architecture

Customer channels
Web storefront
Mobile app
Commerce
Catalog
Checkout
PromotionsGap
Platform services
Shared capabilities every domain builds on.
Identity
Event bus
Legacy ESB
LegendCurrentTargetNewGapGapDeprecated
ArchitectureDocs →

Use case diagram

A UML use-case diagram — actors outside the system boundary, use cases inside, include / extend / generalize relations.

SECTION 01 · Use cases
USE CASE
Use-case diagram: Ticketing, 3 actors, 4 use casesTicketingBuy ticketPay by cardRequest refundApprove refundCustomerSupport agentSYSPayment gateway«include»«extend»
Legenduse caseexternal systemassociation«include»«extend»
ArchitectureDocs →

Package diagram

A UML package diagram — tabbed folders with their members on a grid, dashed import / use dependencies between them.

SECTION 01 · Packages

Backend module layout

PACKAGES
Package diagram: 4 packages, 4 dependenciesapiroutesmiddlewaredomainorderspaymentsinventoryinfrapostgreskafkastripesharedidsmoneyclock«use»«import» ports only
Legendpackagedependency«import»import«use»use
ArchitectureDocs →

Flows & state

11 blocks

Sequence diagram

Messages between actors over time (lifelines + returns).

SECTION 01 · Sequence
SEQUENCE
Sequence diagram: 3 messages between 2 actorsClientServerALT[cache hit][miss]1request2200 cached3200 fresh
Legendcallresponsethe answer the caller getsfragment (alt / opt / loop)active
Flows & stateDocs →

Flowchart

A decision flowchart with branches and error exits; `variant: dag` renders a pipeline DAG.

also: dag

SECTION 01 · Flowchart

Decision flow

FLOW
Flowchart: 5 stepsStartIs valid?ProcessRejectDoneyesno
Legendstartstepdecision (diamond)exitnexterror pathhappy path
Flows & stateDocs →

State machine

A state machine — states + event transitions.

SECTION 01 · State machine

Order lifecycle

STATE
State machine: 4 states, 3 transitionsPENDINGCONFIRMEDcreatepayship
Legendstartstatewaitingtransitionsuccess exit
FromEventGuardTo
s0createPENDING
PENDINGpayCONFIRMED
CONFIRMEDshipend
Flows & stateDocs →

Data-flow diagram

Data-flow — processes, external entities, and datastores.

SECTION 01 · Data flow

Data flow

DFD
Data-flow diagram: 3 nodes, 2 flowsEXTClient1ProcessDBOrdersrequestwrite
Legendprocessdata storedata flowexternal entity
Flows & stateDocs →

Swimlane diagram

Who does which step, in what order — one lane per owner, columns from the links, phase bands.

SECTION 01 · Process

Cross-functional flow

LANES
SwimlaneCustomerSalesOpsINTAKEDELIVERYSubmit requestDECISIONQualifyFulfillSLA 2 daysReceiveapprovednotify
LegendstartstepDECISIONdecisionendfocal stepnextmessage
Flows & stateDocs →

How-to steps

A numbered how-to / runbook stepper — title, body, command, note per step.

SECTION 01 · Steps

Deploy a hotfix

  1. Branch from main

    Hotfixes always branch from the latest main.

    bash
    git checkout -b hotfix/fix-retry main
  2. Ship the fix

    Commit and push; CI runs the full suite.

    bash
    git push -u origin hotfix/fix-retry

    CI must be green before the next step.

  3. Tag and deploy
    bash
    git tag v1.4.1 && git push --tags
Flows & stateDocs →

Cycle

A closed loop of stages arranged in a circle — build–measure–learn, PDCA, an incident loop; step descriptions become a numbered legend.

SECTION 01 · Cycle

Build–measure–learn

CYCLE
Cycleevery releaseBuild1Measure2Learn3
1Build — Ship the smallest testable change2Measure — Watch the one metric the change should move3Learn — Keep the change or roll it back
Legendstagenext stage
Flows & stateDocs →

Branch graph

A branching and release model — lanes for branches, dots for commits, curves where one forks and merges back; tags mark releases.

SECTION 01 · Branch model

Release model

BRANCHES
Branch graphmainfeaturebaselinespikereview fixesship itv1.2.0
Legendmain (trunk)branchmergev1release tag
Flows & stateDocs →

Saga

A distributed transaction — forward steps left to right with the compensation under each, and the compensating flow drawn back from the step that fails.

SECTION 01 · Saga

Place order

SAGA
Saga: 4 steps, 3 compensationsOrder serviceORCHESTRATOR1inventoryCOMPENSATEDReserve stockCOMPENSATErelease stock2paymentsCOMPENSATEDCharge cardCOMPENSATErefund card3shippingFAILEDBook shipmentCOMPENSATEcancel shipment4notificationsSKIPPEDSend confirmation
LegendORCHESTRATORcoordinates every stepstepcompensationfailure pointCOMPENSATEDundoneskippednextnot reachedcompensating flow
Flows & stateDocs →

Trace waterfall

A distributed-trace waterfall — one lane per service, each span a bar on a shared time axis, nested by parent; the critical path is marked.

SECTION 01 · Trace

GET /orders/{id}

SPANS
Trace waterfall: 5 spans0 ms20 ms40 ms60 ms80 ms100 ms120 msapidbcacheCACHEpaymentsCLIENTGET /orders/{id}120 ms10 msverify tokenSELECT orders40 ms3 msGET order:42GET /payments/4246 msERR
Legendnested spancritical patherrorCACHEcacheCLIENTclient
Flows & stateDocs →

Timing diagram

A UML timing diagram — one lane per lifeline stepping through states over a shared time axis, with events and duration constraints.

SECTION 01 · Timing diagram

Circuit breaker under a downstream outage

TIMING
Timing diagram: 2 lanes, 2 events0s10s20s30s40s50s60sBreakerclosedopenhalf-openclosedopenhalf-openhal…closedDownstreamhealthydownhealthydownhealthy{ open 30 s }5 failures in 10 sprobe ok
Legendstatefailure statehighlighted stateevent{ }duration constraint
Flows & stateDocs →

Data model

1 block

Entity-relationship diagram

Entities, columns, keys, and crow’s-foot relationships.

SECTION 01 · Entity model
ER
Entity relationship diagram: 2 entities1NAGGREGATE ROOTusers#iduuidENTITYorders#iduuiduser_iduuidPLACES
Legend#primary keyforeign key1 / Ncardinalityaggregate root
Data modelDocs →

File tree

An indented file / folder hierarchy; `variant: issue` renders a MECE issue tree.

also: mece

SECTION 01 · Hierarchy
src
components
hooks
index.tsentry point
Charts & overviewsDocs →

Pyramid

A layered pyramid, widening top → bottom.

SECTION 01 · Pyramid
PyramidVisionLong-term directionStrategyHow we get thereTacticsThis quarterTasksThis week
Charts & overviewsDocs →

User journey

A user journey across stages, with an emotion curve.

SECTION 01 · Journey

Onboarding journey

DiscoverSign upActivatePay
TouchpointLandingFormEmailCheckout
FrictionLowMedLowMed
Emotion
Emotion curve
Legendpositiveneutral
Charts & overviewsDocs →

Gantt chart

A schedule — task bars across date columns.

SECTION 01 · Schedule

Roadmap

GANTT
ScheduleQ1Q2Q3Q4DiscoveryBuildShipGA
Legendplanneddonein progressmilestone
Charts & overviewsDocs →

Node-link graph

A generic node-link graph with colour-cycled groups.

SECTION 01 · Graph

Dependency graph

GRAPH
GraphG0Module AG1Module BG2Module CG3Shared
LegendnodeG1groupedgeundirected (no head)
Charts & overviewsDocs →

Quadrant chart

A 2×2 matrix (e.g. effort vs impact) with plotted items.

SECTION 01 · Matrix

Effort vs impact

2×2
QuadrantEffort →↑ ImpactLowHighHighLowQuick winBig betFill-inThankless
Charts & overviewsDocs →

Data chart

A data chart — bar / line / area / scatter / donut / pie / gauge / radar / waterfall / funnel / histogram / bell / boxplot / pareto / bullet, pure SVG, series coloured by accent.

also: waterfall, funnel

SECTION 01 · Chart

p95 latency by week

CHART
Chart0ms100ms200ms300ms400msW1W2W3W4
Legend/orders/search
Charts & overviewsDocs →

Heatmap

A numeric grid with an intensity ramp — rows × columns of tiles tinted by value.

SECTION 01 · Heatmap

p95 latency by region

HEATMAP
00
06
12
18
us-east-1
120
135
210
265
eu-west-1
110
150
240
190
ap-south-1
180
220
310
280
Legend110–160 ms160–210 ms210–260 ms260–310 ms
Charts & overviewsDocs →

Flow volumes

A flow diagram weighted by volume — node height and ribbon thickness are the value, so the widest ribbon leaving a stage is where the volume actually goes.

SECTION 01 · Flow volumes

Where the cloud bill goes

SANKEY
Flow volumesBill → Compute: 62k62kBill → Storage: 28k28kBill → Network: 10k10kCompute → Batch: 24k24kCompute → Serving: 38k38kBill100kCompute62kStorage28kNetwork10kBatch24kServing38k
Legendstage (height = volume)flow (width = volume)heaviest flow
Charts & overviewsDocs →

Treemap

Proportional composition as nested tiles — area is the value, so thirty items stay readable where a donut gives up at six.

SECTION 01 · Composition

Cloud spend by service

TREEMAP
TreemapCompute62k · 58%EC2 + LambdaCompute: 62k (58%)Storage28k · 26%Storage: 28k (26%)Network10k · 9%Network: 10k (9%)Observability7k · 7%Observability: 7k (7%)
Legenditem (area = value)focal item
Charts & overviewsDocs →

Venn overlap

Two or three overlapping sets, with the shared regions labelled — scope, ownership, responsibility.

SECTION 01 · Overlap

Who owns what

VENN
VennPlatformruntime and CIProductfeaturesRelease process
Legendsetoverlap (darker = shared)
Charts & overviewsDocs →

Fishbone diagram

Cause & effect (Ishikawa) — one effect at the head, cause categories as bones off the spine, specific causes as items along each bone.

SECTION 01 · Cause & effect

Why checkout latency rose

FISHBONE
FishboneCodeSync capture callN+1 cart queryTrafficFlash-sale spikesInfrastructureUndersized DB poolp95 checkoutover 2s
LegendeffectBONEcause categoryspecific cause
Charts & overviewsDocs →

Slopegraph

Ranked before / after — one line per item between two labeled columns; the slopes show what rose, fell, or held.

SECTION 01 · Before / after

Support volume by channel

SLOPEGRAPH
Slopegraph20232025Email: 48% → 22%Email 48%22% EmailChat: 20% → 45%Chat 20%45% ChatPhone: 32% → 33%Phone 32%33% Phone
Legenditemfocal item
Charts & overviewsDocs →

Mind map

A radial mind map — one centre, branches fanning left and right, sub-branches hanging off each; accent per branch.

SECTION 01 · Mind map
MIND MAP
Mind map: Onboarding v2, 3 branchs, 9 nodesOnboarding v2AccountSSO firstTeam invitesData importCSVAPI syncLearningProduct tourTemplates
LegendAccountData importLearning
Charts & overviewsDocs →

User story

One agile story — role / want / soThat + acceptance criteria + links.

SECTION 01 · User story
As a user, I want to do the thing, so that I get the outcome.
Acceptance criteria
Givena preconditionWhenI actThenthe outcome
Planning & backlogsDocs →

Timeline

Phases in order with status dots (done / current / next / future).

SECTION 01 · Roadmap
now
current
Phase 1
What is happening now
next
next
Phase 2
What is next
Legendcurrentnext
Planning & backlogsDocs →

Kanban board

Flexible named columns of cards (Now / Next / Later).

SECTION 01 · Board
Now
Current task
Next
Upcoming task
Later
Eventually
Planning & backlogsDocs →

Pros & cons

Two columns weighed against each other — pros vs cons.

SECTION 01 · Trade-offs

Synchronous vs async

Synchronous
Easy to reason about
One transaction
Asynchronous
Latency-bound
Single point of failure
Planning & backlogsDocs →

Current vs target

Current → target, before / after panels.

SECTION 01 · Before / after

Migration plan

Today
Single monolith
Shared database
Manual deploys
Target
Modular services
Per-service stores
Automated deploys
Migrate one service per quarter.
Planning & backlogsDocs →

Meeting agenda

A meeting agenda — time, duration, owner, topic per row.

SECTION 01 · Agenda
09:00
30m
IntrosHost
09:30
45m
Status updates
Each team for 5 min
10:15
15m
Wrap-up
Planning & backlogsDocs →

Fancy list

A fancy bullet list — accent / check / icon / number marker styles.

SECTION 01 · List

What you get

  • Typed blocks76 strict schemas, validated by chiltepin check.
  • One source of truthDiagrams live in the .md file.
  • Many outputsHTML, slides, and PDF from one file.
Planning & backlogsDocs →

Story backlog

A collapsible backlog of user stories (accordions) in one section.

SECTION 01 · User stories

Backlog

US-1One-step checkout5 ptsHigh

As shopper, I want pay for my cart in one step, so that I finish faster.

Acceptance criteria
  • Given I have items, when I submit valid payment, then an order is created.
US-2Save payment method3 ptsMed

As returning shopper, I want store a card, so that I skip re-entry.

Planning & backlogsDocs →

Design pattern

A design-pattern card — intent · forces · participants · consequences.

SECTION 01 · Pattern
PATTERNRepositoryBackend
Intent
Hide persistence behind a collection-like interface so the domain never sees the database.
Forces
Swap the data storeUnit-test without a DBNo query leaks into the domain
Participants
  • OrderRepositoryinterface the service depends on
  • PgOrderRepositoryPostgres implementation
  • OrderServicecaller (domain logic)
Consequences
  • +Swappable storage
  • +Testable with a fake
  • +Clear seam
  • Another layer
  • Risk of anemic pass-through methods
Planning & backlogsDocs →

Changelog

Release history on a vertical rail — version pills, dates, and typed change chips.

SECTION 01 · Changelog

Release history

2.0.02026-06-24breaking
changedConfig moved from .rc to chiltepin.config.json
removedDropped Node 18 support
1.4.02026-05-12minor
addedDark theme
fixedSlide overflow on long tables
Planning & backlogsDocs →

Risk register

A risk register — severity derived from likelihood × impact, with mitigation, owner, and status.

SECTION 01 · Risk register

Launch risks

highTraffic spike overwhelms the APIPlatformmitigating
L: med · I: high

Mitigation: Autoscaling + load-shedding at the gateway.

highData migration misses edge casesDataopen
L: low · I: high

Mitigation: Dry-run against a prod snapshot.

mediumDocs lag the releaseaccepted
L: med · I: low
Planning & backlogsDocs →

Status table

Task table with an update column, user-defined colored status pills, and optional subtasks per row; `variant: tracker` renders the classic task-tracker list.

also: tracker

SECTION 01 · Status

Workstream status

TaskUpdateStatus
Payment retriesBackoff logic merged; canary running since Mondayshipped
Vendor SSOContract countersigned; sandbox creds due this weekwaiting on vendor
SAML metadata exchangeOur metadata sent Tuesdayshipped
Provisioning syncBlocked on sandbox credentialswaiting on vendor
Rate-limit reworkPR up for second reviewin review
Legendin reviewwaiting on vendorshipped
Planning & backlogsDocs →

Story map

User story map — the ordered backbone of activities across the top, release slices as rows of cards under each step.

SECTION 01 · Story map

Checkout story map

STORY MAP
Step 1
Browse
Find the product
Step 2
Pay
MVP
Search box
Card payment
Later
Filters
Saved carts
Planning & backlogsDocs →

Rollout plan

A progressive-delivery plan — stages left to right with their traffic share, hold time, and the gate each must pass; the rollback move as the footer.

SECTION 01 · Rollout

Checkout v2

ROLLOUTcanary
Stage 1
Smokedone
1%
15m
Stage 2
Canarycurrent
10%
30m
Stage 3
Halfnext
50%
1h
Stage 4
Fullnext
100%
LegenddonecurrentnextGATEgate — must pass to advance
RollbackFlip the flag off; the old version keeps serving.
Planning & backlogsDocs →

Process chevrons

A process chevron strip — N steps left to right with the current one highlighted and a line of detail under each.

SECTION 01 · Process

Incident lifecycle

CHEVRONS
Process chevrons: 5 stepsDetectalert firesTriageseverity + ownerMitigatestop the bleedingResolveroot cause fixedReviewpostmortem in 5 days
Legenddonecurrent stepupcoming
Planning & backlogsDocs →

Roadmap

A roadmap — themes as rows, periods as columns, items as status-tinted chips spanning their periods, with a "now" rule.

SECTION 01 · Roadmap

Platform roadmap 2026

ROADMAP
Roadmap: 3 themes, 4 periods, 6 itemsQ1Q2Q3Q4ReliabilityMulti-region PostgresMulti-region PostgresChaos game daysChaos game daysDeveloper experiencePreview envs per PRPreview envs per PRGolden-path templatesGolden-path templatesCostSpot instances for batchSpot instances for batchEgress cut 30%Egress cut 30%now
Legenddonecurrent — in progressnext / plannedrisknow
Planning & backlogsDocs →

Capability matrix

A role × resource capability grid; cells tint by permission level.

SECTION 01 · Capability matrix

Who can do what

Role / AppBillingReportsAdmin
OwnerFullFullFull
ManagerFullRead
ViewerReadRead
Legendfullpartialnone
Business & decisionsDocs →

Anatomy breakdown

The labelled parts of a delimited string (app:feature:action).

SECTION 01 · Anatomy

Anatomy of a permission

meridian:billing:invoices.read
App
meridian
Which product.
:
Feature
billing
The area within the app.
:
Action
invoices.read
The specific capability.
Business & decisionsDocs →

Access composition

Effective access as intersected gates (A ∩ B ∩ C = result).

SECTION 01 · Composition

How access is decided

Identity
A valid signed-in user.
Scope
The request is in range.
Permission
The action is granted.
=
Effective
May read invoices
Business & decisionsDocs →

Design drivers

A grid of factor cards — the forces that shaped a design.

SECTION 01 · Drivers

What shaped the design

Single sign-on
One login carries the user everywhere.
HOW: token
Read per site
Access is scoped to the sites a user belongs to.
WHERE: site group
Governed roles
An external IGA requests, approves, and certifies access.
WHO: role groups
Per-app permissions
The same role does different things in each app.
WHAT: matrix
Business & decisionsDocs →

Options considered

Approaches explored — pros / cons / verdict; the chosen one highlighted.

SECTION 01 · Options

Approaches explored

Option 1App-managed roles
Roles live in our own DB; SSO only handles sign-in.
  • Full control
  • Second source of truth
  • Custom tooling to govern
REJECTED — fails the constraint
Option 2Global role groups
Site groups for read; one global group per role.
  • Fewest groups
  • Scales linearly
  • A role applies at every site
VIABLE — kept as fallback
Option 3Per-site role groups
One group per persona per site.
  • Least privilege by construction
  • Clean per-site audit
  • Most groups to manage
CHOSEN — matches the constraints
Business & decisionsDocs →

Spec sheet

A labelled spec sheet — label → value rows (a value can be a step-flow).

SECTION 01 · Spec

Per-site role groups

Groups
SiteN-Users (read) + SiteN-<Persona> per staffed plant.
Roles
Each group reads as (site, role); the token carries the full scope.
Resolution
Decode tokenRead (site, role)Check matrix
Cost
Up to Sites x Roles groups; adding a role multiplies them.
Business & decisionsDocs →

Back-of-envelope math

Back-of-envelope capacity math — assumptions, derivation rows, a highlighted bottom line.

SECTION 01 · Capacity math

Write-path capacity

Daily active users
5M
Writes / user / day
4
Writes per day5M × 420M/day
Write QPS20M / 86,400 s≈ 230 rps
Peak QPS230 × 3 (peak factor)≈ 700 rps
Provision for
~1,400 rps (2× peak headroom)
Business & decisionsDocs →

SWOT analysis

A classic SWOT 2×2 — strengths, weaknesses, opportunities, threats as tinted quadrant cards.

SECTION 01 · SWOT

Entering the enterprise segment

Strengths
  • Fastest onboarding in the category
  • Strong developer community
Weaknesses
  • No SSO / SCIM yet
  • Small support team
Opportunities
  • Competitor sunsetting its legacy plan
  • Compliance push creates demand
Threats
  • Incumbent bundling a free tier
  • Procurement cycles slow adoption
Business & decisionsDocs →

OKRs

Objectives and key results — one card per objective, a status-coloured progress bar per KR.

SECTION 01 · Objectives

Q3 objectives

Make onboarding effortlessGrowth
Time-to-first-doc under 5 minutes
70%on-track
Activation rate from 45% to 60%
40%at-risk
Earn enterprise trustPlatform
Ship SSO + audit log
100%done
SOC 2 Type II report issued
20%off-track
Business & decisionsDocs →

User personas

User persona cards — avatar, role, quote, goals, frustrations, and tools.

SECTION 01 · Personas

Who we build for

MC
Maya Chen
Staff engineer
I want the diagram in the PR diff, not in a wiki.
Goals
  • Docs that live with the code
  • Reviewable architecture changes
Frustrations
  • Stale wiki pages
  • Screenshots of whiteboards
Tools
VS CodeGitHub
PP
Priya Patel
Engineering manager
Every reorg breaks our onboarding docs.
Goals
  • One source of truth per system
Frustrations
  • Docs no one owns
Tools
LinearNotion
Business & decisionsDocs →

Team cards

Compact people cards — initials avatar, name, role, and focus area.

SECTION 01 · Team

Who owns what

AR
Ana Ruiz
Tech lead
Rendering pipeline
SO
Sam Okafor
Backend
Sync + integrations
LF
Lena Fischer
Design
Themes and house style
Business & decisionsDocs →

Decision scorecard

A weighted decision matrix — criteria rows × option columns, totals footer, winner highlighted.

SECTION 01 · Decision matrix

Queue technology choice

CriteriaKafkaWINNERself-hostedSQSWINNERmanaged
Throughput×253
Operational cost25
Team familiarity34
TOTAL1515
Business & decisionsDocs →

Wardley map

A Wardley map — components placed by visibility to the user and by evolution (genesis → commodity), joined into a value chain.

SECTION 01 · Strategy map

Where to build

WARDLEY
Wardley mapGENESISCUSTOM-BUILTPRODUCTCOMMODITYEVOLUTION →VISIBLE TO THE USER →AnalystReportingWarehouse
Legendusercomponentcommoditydepends on
Business & decisionsDocs →

Rated comparison

A rated comparison — options across the top, criteria down the side, a Harvey ball for each judgement; the recommended column is marked.

SECTION 01 · Comparison

Vendor fit

CriteriaKafkaSQSRECOMMENDEDRabbitMQ
Throughput×24 of 42 of 43 of 4
Ops burden1 of 44 of 43 of 4
Team familiarity2 of 44 of 43 of 4
Weighted111212
Legendpoorexcellent
Business & decisionsDocs →

Executive summary

An executive summary in Minto order — situation, complication, question, and the answer the deck exists to deliver.

SECTION 01 · Summary
1
Situation

We process 12k orders a day across three regions.

2
Complication

p95 checkout crossed 2s in March and conversion fell 3.1pp.

3
Question

Where does the next quarter of platform work go?

Answer

Move payment capture off the request path — it returns 1.8s of the 2.4s.

  • Capture is 74% of p95 and is fully async-able
  • No schema change, so it ships in one quarter
Business & decisionsDocs →

Scenario table

Base, upside and downside against the same drivers — assumptions in columns, with the outcome each set produces on its own row.

SECTION 01 · Scenarios

Three ways next year goes

DriverDownsideBaseBASE CASEUpside
Volume growth-5%8%15%
Priceflat+2%+4%
Churn12%9%7%
Outcome$18M$24M$31M
Business & decisionsDocs →

Wireframe

Low-fi UI mockups inside device frames (desktop / browser / phone).

SECTION 01 · Mockup

What the user sees

UI
UI mockupapp.example.comHomeInboxSettingsNotificationsMark all as readDesktop9:41100%AlertsHomeSearchBellYouiPhone
Design systemDocs →

Color palette

Color-token swatches on a card grid — hex value, name, and usage per color.

SECTION 01 · Palette

Brand palette

#0E54A1
Primary
Buttons and links
#1F2937
Ink
Body text
#F6F8FB
Surface
Card backgrounds
#1F9747
Positive
Success states
Design systemDocs →

Type scale

A live type specimen — one row per style, the sample rendered at its real size, weight, and font.

SECTION 01 · Type scale

Type scale

Display
40px / weight 700
The quick brown fox jumps over the lazy dog
Body
15px / weight 400
The quick brown fox jumps over the lazy dog
Caption
12px / weight 500
secondary text
The quick brown fox jumps over the lazy dog
Code
13px / weight 400
The quick brown fox jumps over the lazy dog
Design systemDocs →

Do / don't guide

Do / don’t guideline cards — a green DO and a red DON’T column, with optional mono examples.

SECTION 01 · Guidelines

Button usage

Do
Use one primary button per view
Write labels as verbs
Save changes
Don't
Stack two primary buttons side by side
Disable a button without explaining why
tooltip: Add a line item first
Design systemDocs →

Component inventory

A component / feature status board — compact rows with a color-coded stable / beta / experimental / deprecated / planned chip.

SECTION 01 · Inventory

Component status

Buttonv2
stable
Data table
API may change before GA
beta
Date picker
experimental
Modal (legacy)
Use Dialog instead
deprecated
Charts
planned
Design systemDocs →

Algorithms

4 blocks

Array walkthrough

Array cells for algorithm walkthroughs — tones, pointer labels below cells, and a dashed index-window highlight.

SECTION 01 · Array

Binary search — step 2

ARRAY
Array0317212319427541lomidhisearch space
Legendcellcurrenttargetvisited[ ]window
AlgorithmsDocs →

Linked list

A pointer-chain diagram (singly or doubly) — boxed nodes, next/prev arrows, node markers, and a ∅ terminator.

SECTION 01 · Linked list

Reversing a list — step 2

LIST
Linked list9471prevcurrnext
Legendnodecurrentvisitednext
AlgorithmsDocs →

Binary tree

A binary tree — nodes placed by parent + side, tinted to show search paths, traversals, and heap shapes.

SECTION 01 · Binary tree

BST search for 27

TREE
Binary tree198312740
Legendnodecurrenttargetvisited
AlgorithmsDocs →

Hash map

Hash buckets with chained entries — collision chains read left → right as key/value pills; tones highlight probes.

SECTION 01 · Hash map

Chained hash table

HASH
Hash map0apple: 312plum: 9grape: 134fig: 7
Legendbucketentrycurrentout of playcollision chain
AlgorithmsDocs →

AI & agents

6 blocks

Agent loop

The canonical LLM agent loop — environment → agent (model chip) → tools, with memory and a stop condition.

SECTION 01 · Agent loop

Support triage agent

AGENT
Agent loopCustomerTriage agentclaude-sonnet-4-6Routes each ticket to a fixor a human.search_kbSearch help-centerarticlesget_accountLook up plan andbilling statecreate_ticketEscalate to a humanqueue1prompt4response2tool call3resultread/writememoryconversation historycustomer profile
Legendenvironmentagenttool · memoryprompt · tool callresponse · result
stops when: reply sent or ticket escalated
AI & agentsDocs →

Agent trace

An agent execution transcript — user / assistant / tool / system turns, with thinking and tool args → result.

SECTION 01 · Trace

Password reset — one episode

USER
I never get the reset email.
ASSISTANT
Could be a bounce — check delivery logs before blaming spam.
Let me check our email logs.
TOOL
email_logs.search
args:{ "to": "sam@example.com", "type": "password_reset" }
1 result: bounced (mailbox full)
ASSISTANT
Your mailbox rejected the email — free up space and I will resend it.
AI & agentsDocs →

Prompt anatomy

Prompt anatomy — stacked role segments (system / user / assistant / tool) with highlighted {{variable}} chips and a legend.

SECTION 01 · Prompt

Support reply template

SYSTEM— role + guardrails
You are a support agent for {{product}}. Answer from the docs only.
USER
Customer ({{plan}} plan) asks: {{question}}
{{product}}Product name from config
{{plan}}Plan tier of the signed-in customer
{{question}}The inbound message
AI & agentsDocs →

Context-window budget

A context-window token budget — one stacked bar sized against the window, with free space and over-budget overflow.

SECTION 01 · Context window

Where the window goes

CONTEXT
Context windowwindow: 200,000 tokens12retrievalhistoryfree (50,000)
Legend
1system prompt6,000 tokens · 3%
2tool schemas14,000 tokens · 7%
3retrieval60,000 tokens · 30%
4history70,000 tokens · 35%
AI & agentsDocs →

Neural network

A layered neural network — one column per layer with unit counts, kinds (input / conv / dense / attention / output) and activations; dense wiring drawn between layers.

SECTION 01 · Neural net

Digit classifier

NEURAL NET
Neural network: 6 layersInput78428×28 pixelsConv 3×332ReLUMax pool32Dense128ReLUDropout 0.3128Output10softmax
Legendinputconvpooldensedropoutoutput
Params 1.2M
AI & agentsDocs →

Model card

An ML model card — identity, intended use and out-of-scope, training data, metrics per split, limitations; the endpoint card for a model.

SECTION 01 · Model card
MODEL·3.2.0support-intent-v3taskText classification (support ticket intent)
architectureDistilBERT fine-tune, 6 layers
params66M
ownerML platform
licenseInternal
Intended use
  • Route inbound tickets to one of 14 queues
  • Suggest a queue to an agent; never auto-close
Out of scope
  • Any language other than English and Spanish
Training data
  • 410k tickets, 2024-01 to 2025-06, PII scrubbed
Metrics
MetricValueSplitNote
Macro F10.91test
Latency p9538 msprodCPU, batch 1
Limitations
  • Confuses billing and refund intents on short tickets
AI & agentsDocs →

Audit findings

An audit findings register — severity-ranked rows with evidence, fix, owner and status, and a count strip per severity.

SECTION 01 · Audit findings

Security review — payments service

scopepayments-api, payments-workerdate2026-09-01auditorAppSec
4 findings1 critical1 high1 medium1 info
IDSeverityFindingEvidenceFixOwnerStatus
F2criticalCard BIN logged at INFOLoggingworker.log line 2231Mask to first 2 digits; add the log-scrub testpaymentsopen
F1highRefund endpoint has no rate limitAPIPOST /refunds accepted 500 req/s in the load testAdd the shared limiter at 20 req/min per keypaymentsfixing
F3mediumDependency openssl 3.0.8 has a known CVESupply chainBump to 3.0.14platformfixed
F4infoHealth endpoint leaks build SHAAPIaccepted
Quality & auditsDocs →

Checklist

A pass / fail checklist with evidence — items or grouped items with a verdict chip and the evidence behind each; pass rate derived.

SECTION 01 · Checklist

Production readiness — search-indexer

PRR v4
Observability
pass
Dashboards for the four golden signalsgrafana/search-indexer
pass
Alerts route to the on-callpagerduty svc P4
partial
Traces sampled at 10%target is 100% on errors
Resilience
fail
Load test at 2× peaknot run since the Kafka move
n/a
Multi-region failoversingle-region service by design
2 pass · 1 fail · 1 partial · 1 n/apass rate 63%
Quality & auditsDocs →

Performance budget

Performance budgets against measured values — one bar per metric with the budget mark; over / near / within derived.

SECTION 01 · Performance budget

Product page — web vitals

PERF BUDGET
Performance budget: 5 metricsp75, mobile, 4G, 30-day field databudgetLCPbudget ≤ 2500ms2140msokINPbudget ≤ 200ms260msoverCLSbudget ≤ 0.10.04okJS transferredbudget ≤ 300KB285KBnearLighthouse perfbudget ≥ 9084over
Legendover budgetnear — within 10%within budgetbudget
2 over1 near2 ok
Quality & auditsDocs →

Latency percentiles

Latency percentiles per row — p50 · p90 · p95 · p99 · max as a dot-and-whisker on one axis, with the SLO line.

SECTION 01 · Latency percentiles

Checkout API latency — last 7 days

PERCENTILES
Latency percentiles: 3 rows0ms1000ms2000ms3000ms4000msSLO 300msPOST /checkout420GET /cart90POST /payments240900
Legendp50p90 · p95p99p99 over the SLOmaxSLO
Quality & auditsDocs →

Threat model

A STRIDE threat model — data-flow shapes inside dashed trust boundaries, plain hops marked, and a threats table keyed to nodes and edges.

SECTION 01 · Threat model

Login — STRIDE

THREAT MODEL
Threat model: 3 nodes, 2 flows, 3 threatsTrusted networkInternetEXTBrowserAuth serviceDBUsers DBPOST /loginSELECT by email
Legendprocessexternal entitydata storetrust boundarytls (lock)internal
IDSTRIDETargetThreatMitigationSeverityStatus
T1SBrowserCredential stuffingRate limit + breached-password checkhighmitigated
T2IAuth serviceVerbose error reveals whether the email existsOne generic messagemediumopen
T3TUsers DBPassword hash column altered by an adminAudit log + Argon2idhighaccepted
Quality & auditsDocs →