A practical architecture document template for systems and decisions

Using only the source material and requirements I provide, create the complete document as raw GitHub-Flavored Markdown (.md). Do not generate, attach, or encode a DOCX/PDF; use the response budget for accurate, useful content.

OUTPUT CONTRACT
- Return only the finished Markdown document: no preamble, commentary, or code fence around the whole response.
- Use exactly one `#` H1 for the document title, then sequential `##` and `###` headings without skipping levels.
- Keep paragraphs concise, sections complete, terminology consistent, and the hierarchy easy to scan.
- Never invent facts, metrics, quotations, requirements, URLs, or citations. Mark missing inputs as `[TBD: specific information needed]`.
- Do not add HTML, manual page numbers, a manually typed table of contents, base64 data, or decorative filler. Unmarkdown generates pagination and the table of contents from the heading structure.

MARKDOWN TOOLKIT — use each feature only when it improves the document
- `**bold**` for labels or key terms, `_italic_` for light emphasis, and `~~strikethrough~~` only for explicit revisions.
- Unordered `-` lists, ordered `1.` steps, and `- [ ]` task lists for actions or review checklists.
- `> blockquotes` for warnings, decisions, constraints, or important callouts.
- GFM tables with a header and separator row; keep every row the same width and keep cells concise.
- Fenced code blocks with a language tag such as `json`, `yaml`, `bash`, `typescript`, or `sql`; never use a fence around the whole document.
- Mermaid diagrams in a fenced `mermaid` block when a flow, sequence, architecture, state, or dependency diagram adds real value.
- Descriptive links as `[label](https://example.com)` and `---` rules only between major document parts.
- Prepare a separate alphabetical Index page by marking important terms at their first relevant mention with `[[index: Term]]`. Use `[[index: Primary term: Subentry]]` for a nested entry. Do not type an Index heading, page numbers, or the index list yourself; Unmarkdown generates the final Index page and page references during Word export.
- Escape Markdown control characters when they are meant to appear literally.

DOCUMENT STANDARD
Build a practical software architecture document that explains structure, behavior, operations, and decisions.
- Include goals/non-goals, context, constraints, quality attributes, components, interfaces, data model/flows, security, deployment, scalability, observability, failure handling, and risks.
- Add appropriate Mermaid diagrams for system context, containers/components, sequence, deployment, or data flow; keep each diagram focused and syntactically valid.
- Include an ADR table: `ID | Decision | Status | Rationale | Alternatives | Trade-offs`, plus interface/configuration code blocks with language tags.
- State assumptions and use `[TBD: evidence or decision]` where architecture input is missing.

FINAL QUALITY CHECK
- Verify heading order, table column counts, list indentation, code-fence pairing, requirement/decision IDs, and internal consistency.
- Remove empty sections and generic filler. Preserve `[TBD: ...]` markers instead of guessing.
- End with the final document content, ready to save directly as a `.md` file and convert in unmarkdown.in.