Product requirements
Purpose, non-goals, workflows, evidence model, and the narrow contract-change review question.
Docs
Start from the documents that define the evidence boundary.
This page maps the public docs that explain what TraceMap is building, how validation works, what counts as acceptance, and where language adapters must preserve deterministic, rule-backed evidence.
Validation guide
Repeatable local checks, public demo expectations, pinned smoke guidance, and generated-output safety rules.
Acceptance plan
Artifact, reducer, export, evidence, and coverage criteria that define when behavior is acceptable.
Language adapter contract
Shared expectations for adapters that emit facts, relationships, reports, and reducer-compatible evidence.
Decisions
Architecture and product decisions that explain why TraceMap favors deterministic extractors and explicit limits.
Next execution report
Current runway notes, coordination state, and near-term execution context for future agents and maintainers.
How to read them
The docs are guardrails, not marketing copy.
Start with scopeUse the PRD to understand what TraceMap should and should not claim.
Map capabilitiesUse the capability map to see status-labeled workflows, adapter maturity, and demo-safe surfaces.
Check proofUse validation and acceptance docs to see how behavior is verified.
Respect limitsUse decisions and adapter contracts to keep rule-backed evidence portable across languages.
Track runwayUse execution notes for current context, but treat implemented specs and code as stronger evidence.
The repository remains the source of truth.
The site gives humans and bots a stable entry point, but the canonical documents live in the public repository. TraceMap documentation should keep pointing back to code, rules, tests, specs, and generated evidence.