|
| 1 | +# Documentation Writing Guide |
| 2 | + |
| 3 | +Guidelines for writing dstack documentation, README, and marketing content. |
| 4 | + |
| 5 | +## Messaging |
| 6 | + |
| 7 | +- **Primary keyword**: "Confidential AI" — use in tagline and first paragraph |
| 8 | +- **Secondary keyword**: "Private AI" — use in explanatory context |
| 9 | +- **Key differentiator**: NVIDIA Confidential Computing support (H100, Blackwell GPUs) |
| 10 | +- **Base images**: `dstack-nvidia-0.5.x` for GPU TEE support |
| 11 | + |
| 12 | +## Writing Style |
| 13 | + |
| 14 | +- **Don't over-explain** why a framework is needed — assert dstack as the solution, hint at alternatives being insufficient |
| 15 | +- **Avoid analogies as taglines** (e.g., "X for Y") — dstack is a new category, not a better version of something else |
| 16 | +- **Problem → Solution flow** without explicit labels like "The problem:" or "The solution:" |
| 17 | +- **Demonstrate features through actions**, not parenthetical annotations |
| 18 | + - Bad: "Generates quotes (enabling *workload identity*)" |
| 19 | + - Good: "Generates TDX attestation quotes so users can verify exactly what's running" |
| 20 | + |
| 21 | +## Architecture Descriptions |
| 22 | + |
| 23 | +When describing components for security researchers: |
| 24 | +- Explain **what each component does** (actions) |
| 25 | +- Show **how features emerge** from the architecture naturally |
| 26 | +- Map components to security properties: |
| 27 | + - Guest Agent → workload identity, key isolation, disk encryption |
| 28 | + - KMS → code governance, key derivation bound to attested identity |
| 29 | + - Gateway → encrypted networking, RA-TLS |
| 30 | + - VMM → Docker Compose native, reproducible OS, GPU allocation |
| 31 | + |
| 32 | +## Target Audiences |
| 33 | + |
| 34 | +**Developers** care about: |
| 35 | +- Easy onboarding (Docker Compose native) |
| 36 | +- No code changes required |
| 37 | +- Existing workflow compatibility |
| 38 | + |
| 39 | +**Security researchers** care about: |
| 40 | +- Trust model (what's trusted, what's not) |
| 41 | +- How attestation proves code integrity |
| 42 | +- How key management prevents operator access |
| 43 | +- How code governance is enforced on-chain |
| 44 | + |
| 45 | +## Feature-to-Component Mapping |
| 46 | + |
| 47 | +| Feature | Component | How it works | |
| 48 | +|---------|-----------|--------------| |
| 49 | +| Workload identity | Guest Agent | TDX attestation quotes | |
| 50 | +| Isolated keys | Guest Agent + KMS | Per-app key derivation bound to attested identity | |
| 51 | +| Encrypted by default | Guest Agent (disk) + Gateway (TLS) | Ephemeral disk keys, RA-TLS | |
| 52 | +| Code governance | KMS | On-chain smart contract policies | |
| 53 | +| Docker Compose native | VMM | Direct parsing, no translation | |
| 54 | +| Reproducible OS | VMM | Deterministic image builds | |
| 55 | +| Confidential GPUs | VMM + hardware | NVIDIA H100/Blackwell allocation | |
0 commit comments