Lead with the reader task
Start pages with what the reader can evaluate, run, compare, or verify now, then introduce background only when it supports that task.
Docs style guide
Verification RequiredWrite docs that stay precise, useful, and reviewable.
Use this guide when drafting, reviewing, or correcting Stornamics docs copy. It keeps voice, structure, examples, claims, status labels, limitations, and product-specific wording aligned with the evidence already published on the site.
Voice
Prefer narrow claims
Describe the exact route, command, status row, runtime, or evidence source instead of summarizing a whole product area from one example.
Keep maturity visible
Use the page maturity label, surface-specific status rows, and limits language whenever a feature spans live, beta, alpha, preview, or future work.
Write for handoff
Give support, product SMEs, and docs reviewers enough product, owner, evidence, and validation context to accept or correct the page quickly.
Page Structure
| Section | Required answer | Review cue |
|---|---|---|
| Opening | Who is this for, what can they do now, and what maturity label applies? | The opening does not promise more than the status page supports. |
| Prerequisites | Which local tools, sample data, credentials, or product surfaces are needed? | Optional and unavailable setup paths are marked before commands. |
| Steps or reference rows | What does the reader run, inspect, compare, or configure? | Each runnable path has expected output, cleanup, or evidence. |
| Limits | Which behavior is unsupported, review-bound, future-facing, or product-specific? | Limits are close to the claim they constrain. |
| Next steps | Where should the reader go for status, compatibility, evidence, operations, or support? | Next steps route to existing pages instead of creating orphan paths. |
Product Wording
| Product | Preferred wording | Avoid until reviewed |
|---|---|---|
| ObjectDB | Use scoped S3 Core gateway, local adapter limits, bucket/object workflow, and native API preview contract. | Avoid broad S3 parity language, unscoped durability promises, or native API wording that sounds like a current customer surface. |
| Message Broker | Use controlled-beta streams, replay, cursor, queue, HTTP route family, CLI, SDK, audit, and metrics wording. | Avoid Kafka listener wording, replication commitments, or queue behavior that is not tied to a documented route. |
| Concordia | Use product family, local Cache, Gateway alpha readiness, Storage validation, Time Series shell, and active compatibility service. | Avoid wording that makes Concordia sound like one finished database or implies Gateway, placement, or storage guarantees beyond evidence. |
| LogDB | Use OTLP logs/traces ingest, WAL-backed publication, segment bundle, retained-record query, and BYOC review boundary. | Avoid metrics/profile ingest, S3 publication, replay, or BYOC availability wording unless the owning page and evidence say so. |
| Cross-product | Use status dashboard, compatibility matrix, limits page, evidence index, and product hub as the decision chain. | Avoid merging product maturity states into one umbrella claim or transferring evidence from one product to another. |
Examples And Code
Commands
Evidence required
Show copyable commands, required environment values, expected output, cleanup, and the route or script that validates the result.
Snippet or tutorial smoke coverage, or reviewer-run rationale.
SDK snippets
Evidence required
Name the SDK, version or source boundary, endpoint assumptions, retry behavior, and unsupported paths.
Example manifest status and linked route evidence.
Configuration
Evidence required
Separate required values, optional values, local-only defaults, and review-bound deployment settings.
Reference source, configuration table, or owner-reviewed runbook.
Screenshots and diagrams
Evidence required
Pair each image with nearby text that carries the same meaning and avoids hidden claim upgrades.
Diagram accessibility review or source note.
Status Labels
| Label | Use when | Wording pattern |
|---|---|---|
| Live | The route or command is implemented and validated for the documented case. | Use: documented route, validated command, expected output. |
| Controlled Beta | A selected evaluation or pilot path exists with explicit support and claim boundaries. | Use: controlled-beta surface, selected evaluation path. |
| Alpha | Behavior is local, constrained, or evidence-bound and needs visible limits. | Use: local alpha route, constrained validation path. |
| Preview Contract | Contracts, fixtures, or SDK shapes exist before a complete customer runtime. | Use: preview contract, fixture-backed shape. |
| Future | The copy describes direction, planned work, or a not-yet-current workflow. | Use: planned direction, future-facing workflow. |
| Verification Required | A claim needs product, legal, security, compliance, operations, support, or performance review. | Use: review required, evidence pending, owner signoff needed. |
Limitations
Place limits near claims
Put unsupported behavior, review-bound surfaces, local-only scope, and future-facing work next to the sentence or table row they constrain.
Name the next safe path
Point readers to status, compatibility, evidence, product hubs, known limits, or support-bundle guidance instead of leaving a hard stop.
Escalate sensitive language
Route security, privacy, legal, support, availability, durability, scale, and performance wording to the reviewer named by the owning page or contribution path.