portalr¶
The portal into an application built on lattice: an app UI for the people who use it, to chat with its agents and see their artifacts, proposals, rules and runs, and an admin UI for those who run it, to manage access and see feedback, evaluations, usage and spend.
Built, and released
Built and tested: the router and its readers, the app's areas (threads and chat, artifacts, proposals, runs, rules, restricting and sharing a thread), the admin UI (home, access, audit, feedback, usage, traces, logs and health, runs, and the operators' tenants, deployment audit and tools), people shown by email, and the portal question of stackr's template, which mounts it in a generated application. Each area has a scenario in a browser against a test application, and a few run against an application the template generated (ADR-0040), with the UIs' size budgets checked. The guides describe what is built, and the architecture how.
Not built yet: magic links and other sign-in providers. It is on PyPI, and its wheel carries both UIs (Getting started).
Why: lattice has no face¶
Every surface in lattice is an API, a WebSocket or an MCP server, so an application built on it has to build its own UI before anyone can use it. Running one is blind without an admin UI: granting access, reviewing proposals, seeing what users thought of the agent and what each tenant spends all need one, and grantr's model is only usable through one.
lattice RFC-0002 designs that UI once, and portalr is where it is built.
What it does¶
- The browser calls each package's own routes. A chat goes to artifactr's WebSocket, a rule to reflexr's REST, a grant to grantr's API, on one origin with one token. portalr's router serves the UIs and adds only what no package has (ADR-0001).
- Two static apps on Vite, in React 19 and TanStack, sharing a typed
client, whose types are generated from each package's committed documents, and auikit (ADR-0002). - A chat of its own, thin, over artifactr's protocol (ADR-0003).
- A tenant's own observability, in the admin UI: its feedback, evaluations, usage and spend, traces and logs, with deep links out to the tools for operators (ADR-0004, ADR-0005).
- Every read filtered by tenant, in one module, over the stack's shared stores (ADR-0006).
- Permissions asked, never guessed. The UIs ask grantr what the user may do, and the server checks each command again.
RFC-0001 builds these in eight phases after the foundation, and says what each waited on in grantr and the other packages. Phases 1 to 6 and 8 are done. Of phase 7, the template's portal is done, and the scenarios against a generated application and the acceptance steps are not.
Where to go next¶
| If you want to | Read |
|---|---|
| Mount it and sign in | Getting started |
| Use the app | The app |
| Run a tenant | The admin UI |
| Run the deployment | An operator's runbook |
| Know what is withheld and why | What portalr keeps from view |
| See how it is built | The architecture |
| Understand why each part is the way it is | The decision records |
| See the plan, its phases and what each waits on | RFC-0001, and the RFCs |
| Read the design portalr builds | lattice RFC-0002 |
| Use the marks and their colours | The brand page |
| See what has changed | The changelog |
| Contribute | Contributing |