Role-Aware Dashboard Toolkit

Context

An application that lets people change how a system behaves needs more than a settings page. Someone has to be allowed to make the change, someone else may need to approve it, and later everyone needs to see what changed, when, and what happened next. Role-Aware Dashboard Toolkit is a set of Python building blocks for that. Since its first beta on 2026-10-13 it has gained a complete business dashboard built on those blocks, a guide to hosting one, and a round of security changes deep enough to break the old interface on purpose.

What it does

Each layer can be used on its own, from a settings page up to a full review:

• Controls and access: validated controls, role permissions and a switch that freezes all writes. A whole profile is checked against permissions before it is applied, so a denied restore leaves every control unchanged.
• Profiles and audit history: save named configurations, preview the differences, restore them, and record each change. Values whose names mark them as secret, such as passwords, tokens and connection strings, stay out of saved profiles and are hidden in the audit.
• Runs, checkpoints and comparisons: capture snapshots of settings, audit events and measurements, compare them side by side, and preview a replay that checks current permissions again before it applies anything.
• Human review: comments, assignments, sign offs and handoffs on runs or checkpoints, with the decision state and its blockers worked out from those records.
• Investigations and governance: incident timelines, cases that link evidence across runs, and a preview of which actions a policy would allow or block on the evidence supplied.
• Portable evidence: records export in one JSON format with checks on its envelope, and the review example also writes a standalone HTML report.

Use the supplied Streamlit dashboard, add the optional FastAPI routes, or call the Python core, which needs no other packages, from your own application. The application supplies the data, the measurements and the actions.

What stands out

• A working business dashboard as an example. Cedar & Stone Landscaping is a small fictional company run on the toolkit: password accounts, a shared crew schedule and message board, and admin pages for jobs, customers, business metrics and the audit history. Its hosting guide covers first setup, startup checks that run before the server opens, and a checker that tests a live HTTPS address for role boundaries, cookie settings and refused cross site requests.
• Built for coding assistants to read. The installed package carries its own offline guides. inspect --format json reports what the installed version can do, guide start walks through setup, and the starter that init generates includes an AGENTS.md pointing to the installed handbook, so an assistant can check the real version before it changes your application.
• Checks at the moment of change. Permissions are checked again when a change is saved, not only when a page loads. A checkpoint rechecks access after reading its evidence, a replay rechecks before applying old settings, and the record workflow example refuses an edit made against a record that has since changed. The API stores a value exactly as sent or refuses it by name, rather than quietly clamping it.
• Plain about its limits. Decisions, timelines and replay previews describe recorded evidence. The documentation says they do not carry out business actions, prove causation, or show that an outside change happened; the host application keeps those actions and its own permissions.

Evidence

The source is public under the MIT license, with its tests, guides, a changelog, a migration guide from 0.1 to 0.2 and a security policy. Every pull request runs the tests on Linux with Python 3.10 to 3.14, on Windows and on macOS, plus a browser check of the dashboard and a full run of the landscaping demo. A dependency audit runs on each pull request and weekly, and it fails on an incomplete scan as well as on a known vulnerability.

The Operator Review Lab example runs a complete review on synthetic data with no model account or outside service: save a baseline, capture a candidate, compare the two, record an approval with a reason, and download the evidence as JSON or a standalone HTML report.

Current state

Release candidate 0.2.0rc1, distributed as GitHub source for Python 3.10 and later; 0.1.0 (2026-10-13) is the latest tagged beta. Version 0.2 changes some behavior on purpose, and its migration guide lists what a 0.1 application must update. The demos let whoever is using them pick a role, so they show permissions, not identity; shared use needs an outside identity provider, which the authenticated starter is set up for. The tests and examples have a limited scope and are not a security certification, so evaluate it with synthetic data first and run its deployment checks before admitting real users or private data.

Next, on public branches

Work since 2026-10-18 sits on public branches not yet merged into main, with the latest round in draft pull request #8. It adds Westbridge, a second fictional business: a public notice board where guests post for an administrator’s approval, staff accounts, authenticator codes for the administrator, and passkeys for local trials. A read only Security Lab page walks through three disposable security exercises and shows a receipt of each run with secrets removed, tied to the exact source it ran on. A seeded random test runner sends altered requests to the API and checks that a refused request never grants access or publishes a post. The automated checks pass on the pull request; none of this is in a release yet.