Smart Document Processing Documentation¶
Last verified: 2026-07-26 against dev at f0388abb.
This documentation set is organized with the Diataxis model:
tutorials, how-to guides, reference, and explanation. The product/
section adds the product context that Diataxis intentionally does not cover.
Start Here¶
| Need | Start with |
|---|---|
| Understand what SDP is | Product overview |
| Understand users and use cases | Users and use cases |
| See the product capability map | Capabilities |
| Run the app locally for the first time | Tutorial: first local run |
| Complete an implementation or ops task | How-to guides |
| Look up exact APIs, config, or tenancy rules | Reference |
| Understand architecture and design choices | Explanation |
| Find operational support procedures | Runbooks |
| Check repository/project status | Status |
Documentation Map¶
Product¶
Tutorials¶
How-to Guides¶
- How-to guide index
- Create a schema or processor
- Create an extractor
- Run extractor workers locally
- Run evaluation experiments
- Onboard a consuming app with BYOK
Reference¶
Explanation¶
- Explanation index
- Architecture
- Document processing flow
- BYOK LLM key model
- Evaluation model
- Project status
Design specs¶
Point-in-time design records.
Component Docs¶
The component READMEs remain the source of truth for detailed setup and implementation-specific commands.
- Root README
- Backend
- Frontend
- Extractor apps
- Smart chunking
- Phoenix / Arize evaluation
- Design docs
- Status docs
- Documentation audit
Maintenance Rules¶
- Keep each page focused on one job: tutorial, how-to, reference, or explanation.
- Link to component READMEs for long command lists and implementation details.
- Update the "Last verified" line when a doc is materially checked against the current repository state.
- Keep design notes in
docs/specs/, but link them through this docs map so readers know whether they are active, draft, or historical.
See Documentation standard for the full house style.