Skip to content

Document Format

Every document follows the <slug>.<type>.md pattern. See Documents & Layout for full naming rules, valid types, and directory organization.

Every document requires YAML frontmatter with title and status:

---
title: Use PostgreSQL as Primary Database
status: accepted
---
FieldTypeDescription
titlestringHuman-readable document title. Must not be empty
statusstringDocument status: draft, accepted, or rejected
StatusMeaning
draftWork in progress (default for new documents)
acceptedFinalized or approved
rejectedSuperseded, abandoned, or declined (preserves history)

Cross-cutting labels for multi-axis categorization. Tags let you annotate documents by team, domain, or topic — dimensions that directory structure alone cannot express.

---
title: E2E Auth Flow Testing
status: accepted
tags:
- frontend
- team:backend
- payment_flow
---

Tags must match ^[a-z][a-z0-9_:|-]*$ — lowercase, with hyphens, underscores, colons, and pipes allowed. Colons enable namespace-like conventions (e.g., team:payments). Tags are stored sorted and deduplicated. Invalid tags are rejected with a “did you mean?” hint.

When tags are absent, the field is omitted from output. Documents without tags parse and work normally.

The meta field can hold arbitrary YAML metadata:

---
title: API Rate Limiting Standards
status: accepted
meta:
author: team-backend
reviewed: 2025-01-15
---

After the frontmatter, content is standard Markdown. Each document type has recommended sections (generated by the template), but the structure is not enforced beyond frontmatter validation.

Documents may reference source code using @-notation:

See the implementation at @cmd/init.go and @internal/config/config.go.

This is optional but helps agents navigate between documentation and code.

When creating a document through the MCP create_document tool without providing content, Archcore generates a template with all required and recommended sections for that type.

For example, an ADR template includes:

## Context
[Describe the situation and problem]
## Decision
[What was decided and why]
## Alternatives Considered
[Other options that were evaluated]
## Consequences
### Positive
- [Benefit 1]
### Negative
- [Trade-off 1]
### Risks
- [Risk 1]
## Implementation Notes
[Key implementation details]
## References
- [Link 1]