Console Tour

The fastest way to understand Kaiten's model is to look at a populated one. This tour walks the console over the Kaiten Sushi Shop demo — a restaurant-software vendor with four customers and six instances on three License families — and stops at the five views you will use most.

Get demo data

task dev          # the stack, its accounts, the Kaiten Sushi Shop dataset, and the console

KAITEN_CONTAINER_PREFIX=kaiten-oss docker compose -p kaiten-oss run --rm seed-data

What the seed creates

The dataset carries its own history — when instances were created, and the deployment journal — and seeding dates it relative to the moment you run it.

Stop 1 — Customers

Open Customers in the sidebar. Four restaurant groups, four commercial situations:

• Sakura Tokyo — production on Premium, the highest entitlement values, and a sales demo on Starter: one customer, two instances, two Licenses.
• Ninja Osaka — production on Starter, the tight limits, and a delivery pilot on the second version of Standard, the one that grants delivery tracking.
• Demo Restaurant — on Standard, in between.
• Kappa Kyoto — on the first version of Premium, kept after that version was withdrawn from sale.

Click any of them: the customer page's Instances card lists where the product runs for that customer, and which License each instance is under. That customer → instance → license chain is the spine of everything else in this tour.

✕

✕

✕

✕

Stop 2 — Licenses and their entitlements

Open Licenses, expand a family, and open one of its versions. Each product is a family of versioned License objects, and a version's page holds the table that matters, Entitlements & limits: the entitlements it grants, with their values — the contract side of the model. Next to each numeric value sits the grant's overage allowance: how far usage may run past the value before a report is refused.

A family serves its default version, or else its newest published one: Standard keeps serving v1 although v2, which adds courier tracking, is on sale. Premium's v1 is withdrawn from sale — no new instance can be given it, while Kappa Kyoto keeps it — and v3 is a draft that nothing serves yet.

The numeric entitlements are metered quotas — instances report usage against them, and the allowance is written on each grant, so the same entitlement is hard-capped on Starter and tolerant on Premium. Premium's Locations grant is the unlimited sentinel: no cap, no allowance. The boolean delivery-tracking is an included-or-not right — the one the flag in Stop 4 reads. The configuration entitlement support-tier carries a JSON value per License: the support channels and response commitment each tier includes.

✕

✕

The console writes a boolean grant as Enabled or Disabled, an allowance of zero as Hard limit, and a configuration grant as Configured.

Stop 3 — Usage against the grants

Open Customers → Ninja Osaka, then its instance ninja-osaka-prod, then the Entitlements & Usage tab. Every meter reads the observed usage against the grant — its percentage measured against the most the grant allows, the value plus its allowance — and the seed puts each instance in a different situation:

• Ninja Osaka (Starter) — Menu Items at 5 of 5: at the hard cap, the meter at 100 % — Limit reached — so the next report that would push the total past 5 is refused; Locations sits at its cap too, 1 of 1. Monthly Orders at 18 of 20, inside the current calendar month — the view shows the window's start and end.
• Sakura Tokyo (Premium v2) — Menu Items at 42 of 50, a meter at 70 % of the 60 that Premium's 20 % allowance permits; Locations at 3 against an unlimited grant.
• Demo Restaurant (Standard v1) — Menu Items at 6 of 10 and Monthly Orders at 41 of 100, comfortably inside a grant that tolerates 10 % overage.
• Kappa Kyoto (Premium v1) — Delivery Drivers at 5 of 5: the first version's value, and the reason to move the instance to v2, which grants 10.

Nothing on this screen was typed in: the seeder wrote the totals that usage reports leave behind — the same record your product's backend builds as it reports. The quickstart sends a few and watches a cap push back.

✕

✕

Stop 4 — Feature flags

Open Feature Flags. The one to inspect is delivery-tracking-enabled: its targeting rule lists no customers: it reads the delivery-tracking entitlement through a CEL expression. Sakura Tokyo and Kappa Kyoto resolve to on because their versions of Premium grant the entitlement; Ninja Osaka resolves to off because Starter does not grant it, and so does Demo Restaurant, whose version of Standard does not either. Upgrade a License, and the flag follows — no flag edit involved.

Also worth a look: promo-banner (an object flag, whose variants carry payloads, serving its salmon-week variant to the Standard and Premium families), analytics-dashboard-enabled (a rule combining a server-side fact with context your product sends), and random-discount (a 50/50 rollout).

✕

✕

Stop 5 — Service accounts

Open Integrations → Service Accounts. The seed created two machine identities: Ops Team, the account the whole seed acted as — everything it seeded records it as its creator — with a token that writes the control plane, and SDK, whose token reads feature flags and entitlements. Their secrets were never printed. Generate a token of your own here (it is shown once) and you can replay this tour over the API, which is what the quickstart does, building the same chain from curl.

✕

✕

What you just saw

One model, five views: who you sell to (Customers), what they bought (Licenses granting Entitlements), what they consumed against it (Usage), how the product behaves for them (Flags reading the contract), and how machines talk to it all (Service Accounts). The quickstart builds this same chain from the API; the core concepts explain each piece.