Tahoe OperationsProject Owner Documentation

Documentation Scope ​

This directory contains living, page-level product and operations documentation for Tahoe. It is written for the project owner first, with compact technical traceability for engineers and reviewers.

• Document owner: Project Owner
• Last verified: 2026-08-21
• Index source revision: 8585554212f515ad61cfa54149d6c1010fddb2ab

Published Specifications ​

The published set covers Investment Management, NAV Management, Vault Operations, and the two wallet concepts used by those workflows. Add other canonical pages as separate files when their documentation is requested. Do not create placeholder documents.

Documentation Standards ​

The website follows the structure and evidence rules below so each new page remains discoverable, source-backed, and maintainable.

File Organization ​

Organize page documents by audience:

docs/
├── index.md
├── fund-manager/
├── investor/
└── public/

Use lower-kebab-case names. A canonical routed page normally owns one file. Complex pages may split major tabs into separate files when each tab represents a distinct operating workflow. Dialogs, sheets, filters, display modes, route aliases, compatibility redirects, and unused view components stay inside the document for their owning canonical page or page state.

Required Page Metadata ​

Every page document must state:

• version;
• maturity;
• audience;
• document owner;
• canonical route and page state;
• source view;
• last verified date;
• source revisions for every repository used as evidence;
• repository confidence and deployed-parity confidence.

Website pages use only the small YAML frontmatter block required for VitePress routing, titles, descriptions, and layout. Operational metadata stays visible in Markdown. Keep content static: no scripts, styles, Vue components, runtime imports, or executable includes.

Capability Classification ​

Record implementation maturity separately from execution responsibility. An operation can be live while being performed by another Tahoe page or an external system.

Maturity Labels ​

Apply labels to individual capabilities as well as to the page overall. A page can be Partial while several operations inside it are Live.

Responsibility Labels ​

Name the owning page, service, or operator whenever it is known. Responsibility does not imply maturity. For example, an External system operation can be Live, Partial, or Unsupported.

Confidence Labels ​

Use Critical, High, Moderate, Low, or Unknown for confidence in a claim. Repository evidence and deployed-environment evidence are separate. Source inspection can establish High repository confidence without proving that the same revision is deployed.

Sources of Truth ​

Use the source that owns each claim:

1. apps/tahoe/src/router/routes.ts for canonical routes and access metadata.
2. The current View, ViewModel, store, and API adapter for visible behavior and client-side orchestration.
3. Registered backend routes, views, schemas, services, and permission constants for API availability, validation, authorization, and state effects.
4. Canonical domain and protocol services for investment, NAV, Treasury Wallet, and lifecycle semantics.
5. Focused tests as evidence that the intended mapping is covered.

Files under apps/tahoe/tasks, root claude-* planning artifacts, and historical gap reports are context only. Do not use them to claim current support without checking the owning implementation and registered backend route.

Development mock data is not evidence of production support. When deployed parity has not been checked, record it as Unknown.

Page Document Contract ​

Each page document should cover:

1. purpose and operating boundary;
2. actors and backend permissions;
3. entry conditions and upstream dependencies;
4. information shown and its source;
5. available actions and exact state effects;
6. state transitions and external handoffs;
7. loading, empty, disabled, failure, retry, and reconciliation behavior;
8. capability maturity and known gaps;
9. an owner operating checklist;
10. a compact technical traceability appendix;
11. revision history.

Define business language precisely. In particular, do not collapse onboarding status into KYC status, recorded NAV into finalized dealing NAV, manager acceptance into share issuance, or a submitted chain operation into a confirmed result.

Maintenance ​

Update the owning page document whenever a route, action, permission, status, API contract, integration boundary, or displayed source of truth changes. Refresh the last-verified date and source revision in both the page document and this index. Keep current behavior separate from gaps and planned work.

For a documentation-only change:

• compare every operational claim with its owning source;
• verify relative links and heading structure;
• scan for executable Markdown patterns;
• run git diff --check;
• request an independent source-based review for lifecycle or permission flows.

The Tahoe SPA does not render this directory. The tahoe-docs VitePress application publishes it, and the root content lint scans it. A successful site build proves that the content renders, but it does not prove that the operational claims remain accurate.