Configure what the demo guide shows. Two views — what a user may change, and what you as admin control.
Honest scope: these settings are stored in your browser's localStorage and affect
this demo guide only. They are not wired to beast.app_settings_schema on vpsm —
that is the real governance layer, and it governs the apps themselves. This page demonstrates the
pattern (four axes, admin-vs-user, declared blast radius) on a surface that is safe to click during a demo.
Admin view. You see every setting plus the four governance axes:
On (does it apply) · Shown (does the user see it) ·
Change (may they move it) · Scope (may they alter its bounds).
Toggling Shown off removes it from the user view entirely; toggling Change off
leaves it visible but locked. This is the same four-axis model the real apps use.
Demo content
Presentation
How to use this in the demo
The three-beat settings reveal
Show the consequence first. On a company card, point at the financial history: "that's five years of figures." Don't open a settings panel yet.
Then show the control. Change financial_years_shown from 5 to 3. The card re-renders. One setting, one visible consequence.
Then reveal the governance. Switch to Admin view here and show that you can hide the setting entirely, or show-but-lock it, or let the user move it only within bounds you set. That is the differentiator — most platforms bury their assumptions; this one surfaces them as governable rows.
Don't open the full 54-setting schema for define-game in a first demo. It reads as complexity, not as control. Save it for a technical audience — that's what demo 2 is for.
Demo settings · Howard · stored in browser localStorage, key ukacq_demo_settings
Not connected to beast.app_settings_schema — see the scope note above.