> For the complete documentation index, see [llms.txt](https://quantixfinance.gitbook.io/quantixfinance-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quantixfinance.gitbook.io/quantixfinance-docs/platform-architecture/user-experience-and-role-workspaces.md).

# User Experience and Role Workspaces

The application is organized around roles. Rather than a single dashboard that tries to serve everyone, each participant works in a space scoped to what they can see and do, and permissions are enforced per role at the contract and interface levels alike.

**Lender workspace.** Lenders browse the marketplace, open a pool to see its delegate, strategy, settlement asset, capacity, fee schedule, first-loss balance, and live metrics, and act on their position — deposit, withdraw, and review historical performance. A lender's own positions and the health of the pools they are in are the center of this space.

**Borrower workspace.** Borrowers track their application through the credit lifecycle, then manage active facilities: outstanding principal, available limit on a revolver, cost of capital, upcoming payments, covenant obligations, and the reporting they owe. Creating a new facility runs through a guided flow — selecting the facility type, entering the terms, and reviewing the structured request before it goes to the delegate.

**Delegate workspace.** Delegates operate the pools they manage. This is the widest workspace: the borrower pipeline and underwriting queue, tools to set loan and pool terms, the pool's first-loss balance and parameters, and the servicing view for monitoring collateral coverage, covenant compliance, and loans at risk across the book.

**Administrator and service-provider views.** Administrators see the controls appropriate to their function — permissioning, pool and delegate admission, and any emergency authority — and nothing beyond it. Service providers interact through the narrow surfaces their role requires.

A single wallet may hold more than one role. A delegate, for instance, is also a capital provider through first-loss. The interface presents the role a participant is acting in rather than collapsing everything into one view, which keeps actions unambiguous and permissions legible.