Maintained guides describe the system as it currently exists. RFCs describe accepted engineering design contracts and must label what is accepted, implemented, and deferred. Historical QA records are point-in-time evidence, not current-state documentation.
Current behaviour belongs in documentation. Future work belongs in GitHub issues. If you find a claim the code does not support, that is a bug — please open an issue.
| Document | Reader | Purpose |
|---|---|---|
| README | Anyone evaluating or running PARTHA | What PARTHA is, what currently works, how to run it locally, and its limitations. |
| CONTRIBUTING | Contributors | The contribution rules: fork-first workflow, claiming an issue, branch naming, rebasing, pull requests, Definition of Ready and Done. Read before opening a PR. |
| Local development and troubleshooting | New contributors | A single walkthrough for starting the backend and frontend, running every test/lint/build command, the local database and API-contract failures you're most likely to hit and how to fix them, and how to report a reproducible issue. |
| SECURITY | Anyone reporting a vulnerability | How to disclose privately. Never open a public issue for a vulnerability. |
| AI provider egress policy | Operators and backend contributors | Deployment-owned provider destination policy, DNS pinning, redirect handling, safe defaults, and required production network controls. |
| Database migration rehearsal and recovery | Operators and backend contributors | Disposable Alembic rehearsal command, supported baseline evidence, production preflight, and truthful restore-based recovery decisions. |
| WCAG 2.2 AA accessibility baseline | Frontend contributors and accessibility reviewers | Reproducible automated coverage for the Phase 0 journeys, the outstanding human verification checklist, confirmed findings, and linked follow-up issues. |
| CODE_OF_CONDUCT | Everyone | Expected conduct and how to report a violation. |
| System Overview | Contributors and maintainers | Current components, ingestion flow, persistence, consumers, trust boundaries, and architectural limitations. |
| Repository Intelligence | Anyone changing analysis behaviour | What is extracted, what is deterministic versus heuristic, how facts are persisted, who consumes them, what consumers must not do, and where evidence and provenance stop. Read this before touching analysis. |
| Repository Intelligence v1 RFC | Contributors on the intelligence track | Accepted architectural contract (RFC-0001, tracking #86) for the snapshot/evidence schema: deterministic entity keys, separate inferred assertions, complete derivation chains, producer identity and producer-version tracking, provenance, immutability, diagnostics, versioning, and total canonical graph hashing. Status: Accepted — independently approved by @SHAURYAKSHARMA24 on Issue #86 and PR #101 on 2026-07-16. The durable snapshot pipeline and product-consumer migration are implemented; §17 tracks the remaining contract gaps. |
| Repository Intelligence relationship resolution | Contributors changing extraction or resolution | The deterministic resolver (Issue #91): how stored observations become resolved edges, the one/zero/many candidate outcomes, and the RI-RES-UNRESOLVED / RI-RES-AMBIGUOUS diagnostics emitted instead of a guess. |
| Repository Lineage RFC | Contributors on the intelligence track | Accepted design (RFC-0002, tracking #298) for owner-scoped repository lineage identity, unlineaged standalone imports, 1-based never-reused sequence allocation, deletion behavior, and database-enforced membership integrity. The implementation-critical PR #328 amendment was explicitly approved by the owner on 2026-08-19, authorizing writing and testing #299. The #322 rehearsal and recovery process remains required against the eventual migration before its implementation PR merges. Revision identity remains governed by RFC-0001 §3. |
| Repository Lineage migration plan | Reviewers of #299 | Implementation-grade current-state, Alembic/backfill, ownership, deletion, concurrency, validation, and rollback plan for #299. RFC-0002 owns the architecture decisions; this document defines how to migrate and test them and contains no runtime change. |
| Repository Intelligence golden benchmark | Contributors on the intelligence track | The versioned golden fixture corpus, independently authored expected facts, explicit mapping to the production support matrices, real-extractor precision/recall and citation validation, repeated-extraction canonical-hash determinism checks, and CI reports for Issue #94. |
| Backend README | Backend contributors | Running the backend, endpoints, configuration, tests. |
| Frontend README | Frontend contributors | Running the frontend, structure, commands, tests. |
| Scripts README | All contributors | What each helper script does. |
New contributor — README → CONTRIBUTING → Local development and troubleshooting → System Overview → the README for your area.
Changing analysis, parsing, or AI grounding — Repository Intelligence, first and in full.
- Describe what the code does today.
- Never present heuristic or generated output as a guaranteed fact.
- Represent evidence only as precisely as the implementation supports.
- State limitations plainly. An honest gap is more useful than an optimistic claim.
- No placeholder documents.
- Documentation changes in the same pull request as the behaviour it describes.
These are not maintained descriptions of current behaviour. Each captures what was checked on a given date and is left unedited so it stays usable as evidence. Where the product has since changed, the record says so at the top rather than being rewritten.
- Internal point-in-time QA notes are preserved in the repository but are not maintained contributor documentation.