Core Concepts

• Core Concepts The custody model, signing model, wallet roles, pricing rules, and lifecycle that every Tahoe workflow builds on.
• Brand Style Guide Logo, color, type, and voice rules — reference before designing or restyling any Tahoe page.

Fund Manager

• Create a Fund Set up, verify, and publish a fund.
• Investors & Onboarding Review onboarding, and manage the investor directory and individual profiles.
• Communications Message investors and share documents through Tahoe.
• Investor Portal Configure your investor portal's domain and branding.
• Investment Management Manage subscriptions, share issuance, redemptions, and claims.
• Ledger Follow investment and redemption activity and understand each status.
• NAV Management Record valuations and manage NAV history, corrections, and exports.
• Vault Operations Monitor vault balances, share supply, and settlement state.
• ERC-7540 Vault Understand requests, fulfillment, claims, pricing, and liquidity.
• Manager Signing Wallet & Fund Holding Wallet Understand the fund wallet, owner signatures, and transaction authorization.
• Fund Treasury Vault Understand the vault contract that holds assets and tracks settlement.
• Redemption Workflow Follow the manager and investor handoffs from business request through Vault settlement and payout.
• Redemption Operations: Potential Issues Review authorization, liquidity, recovery, and batch accounting for the planned redemption workflow.

Investors

• Investor Experience What an investor sees and does across their own portal — Dashboard, Fund Detail, Transactions, Data-Room, Onboarding, Communications, and Settings.

Reference

• Documentation Standards File organization, required page metadata, capability classification, confidence labels, and maintenance rules for this site.

Published Specifications

Document owner: Project Owner · Last verified: 2026-09-14 · Index source revision: 81fbf11a78c1ca5fdd5d9683b529ca7ffe7e8f91

Audience	Canonical page	Page state	Maturity	Document
Fund manager	/core-concepts	Shared concepts referenced by every other page	Live	Core Concepts
All (internal design reference)	/brand-style-guide	Logo, color, type, and voice rules for any new Tahoe surface	Live	Brand Style Guide
Fund manager	/dashboard/funds/create	Create, verify, and publish a fund	Live	Create a Fund
Fund manager	/dashboard/onboarding, /dashboard/investors, /dashboard/investors/:id	Onboarding review queue, Investor Directory, and Individual Investor Profile	Partial	Investors & Onboarding
Fund manager	/dashboard/investor-portal	Domain tab: custom investor-login domain	Partial	Investor Portal
Fund manager	/dashboard/funds/:id	Investment Management tab (investments)	Partial	Investment Management
Fund manager	/dashboard/funds/:id	NAV Management tab (nav)	Partial	NAV Management
Fund manager	/dashboard/funds/:id	Vault Operations tab (vault)	Partial	Vault Operations
Fund manager	/dashboard/funds/:id	Ledger tab (ledger)	Live	Ledger
Fund manager	/dashboard/funds/:id	Manager Signing Wallet and Fund Holding Wallet	Live	Manager Signing Wallet & Fund Holding Wallet
Fund manager	/dashboard/funds/:id	Fund Treasury Vault and settlement lifecycle	Live	Fund Treasury Vault
Investor	Investor Portal app (separate from the fund-manager dashboard)	Dashboard, Transactions, Documents, Onboarding, Communications, Settings	Draft — in progress, not yet finalized	Investor Portal — Investor Experience

The published set covers fund creation, Investors & Onboarding, Investment Management, NAV Management, Vault Operations, Ledger, the wallet and vault concepts used by those workflows, and a draft first page for the investor-facing side. Add other canonical pages as separate files when their documentation is requested. Do not create placeholder documents — the investor-experience row above is a deliberate exception while that page is actively being drafted, not a standing practice.

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
├── core-concepts.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

Label	Meaning
Live	The complete described path is backed by current registered contracts.
Partial	A useful path is live, but at least one stated dependency, state, or handoff is incomplete.
Mock-only	The experience exists only with development or test mock data.
Unsupported	Tahoe has no current page action or registered backend contract for the operation.
Planned	The project owner has explicitly approved future behavior. Never infer this label from a mock or TODO.

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

Label	Meaning
This page	The operation is initiated from the documented page state.
Other Tahoe page	The operation is live in Tahoe but initiated elsewhere.
External system	Another application or service owns the operation.
Manual operator	A person completes an out-of-band handoff.

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. 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, Fund Treasury Vault, and lifecycle semantics.
5. Focused tests as evidence that the intended mapping is covered.
6. Core Concepts for custody, signing, wallet naming, NAV timing, and lifecycle terminology — if any page conflicts with it, Core Concepts wins.

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.