← Sketches · the native app program

A grant and its five states

c1362026-11-10

Purpose, level, scope, window, who, record; none, requested, active, revoked, closed.

Source: c136 initial-prompt.md (Mark's words on c130 D6, 2026-11-09); c136 plan.md §The shape, §Rules R1–R7, D1–D7 (confirmed 2026-11-09), §Patterns (the grant as a story); c130 plan.md D6 ruling; c134 (the plane side), c131 (the Status line), c137 (the grant notice as a message).

▤The grant

one record on the plane (D1); the native app only reads it (D7)

  • Purposeone of four categories and the partner's own sentence: "fix the ClickHouse retention bug, ticket 142"
  • Levelobserve · operate · change, each said in one sentence (R6)
  • Scopethe whole plane, or named parts: one endpoint group, one integration, the database layer
  • Windowstart and duration, 1 h · 1 d · 3 d · 7 d at most; expires on its own, revocable at any moment (R2)
  • Whothe admin who granted; the Qpoint people admitted by name, never a shared account (R4)
  • Recordevery action in the audit log carrying the grant id (access.grant.*, D5); a summary to the admin at close
Four purposes, three levels; the default level per purpose tinted (R3: least level by default, the admin raises it)
PurposeObserveOperateChange
Diagnoselook, change nothing; the investigation before the other threedefaultthe admin raisesthe admin raises
Fixa documented problem; a ticket existsalloweddefaultthe admin raises
Implementa feature the partner asked forallowedalloweddefault
Hot-fixan incident in progressallowedalloweddefault

Observe: read configuration, logs, metrics and the audit log. Operate: observe, plus restart services, run shipped migrations, change settings. Change: operate, plus deploy a build or a hot-fix; the shortest default window. The plan fixes diagnose → observe; the other three defaults are this sketch's reading of the level sentences.

Five states: one component in the layer, one in the kit
1None

the resting state of every plane; a self-hosted plane with no Qpoint reachability simply has no grants (R7)

2Requested

Qpoint asks, naming the purpose, the people and the least level that does the job; nothing is open yet

3Active

the admin granted; the window runs, every action is logged with the grant id and visible live

4Revoked

the admin's one click, immediate; the early exit from active (R5)

5Closed with summary

the window ended on its own; the admin gets what was done; a renewal is a new grant (R2)

The plane · c134 · the web app
▭The grant screen

“Qpoint has access to this plane until Thursday 14:00 (fix · operate). 3 actions so far.” Grant, watch live, revoke in one click (R5).

⬓access.grant.* events

opened · action · revoked · closed, in the same stream as everything else (D5); the opening also goes to the operators as a message (c137)

The endpoint · c131 · the native app
▭The Status line

one line when a grant is active on the plane this endpoint reports to; nothing otherwise. Read-only, with the audit entries (D7).

●The person at the keyboard

sees that Qpoint is in, and why; invisible when working

People on either side
●The partner's org admin

the only one who grants (R1, D2); a second admin for Change, off by default

●Qpoint's mechanic

a named identity (OIDC from Qpoint's IdP) the plane accepts only while a grant names it; an expiring invitation link when the plane cannot reach us (D3). Same API and web app, no back door (D4).

The seven rules
  1. R1 The partner grants. Qpoint never self-grants and never holds standing access.
  2. R2 Every grant ends. Short defaults, seven days at most; a renewal is a new grant.
  3. R3 Least level by default. Diagnose and observe are the defaults; the admin raises them.
  4. R4 Named people. Each action names the person, never "Qpoint support".
  5. R5 The partner can watch. Live while it runs, summarised at close; revocation is one click.
  6. R6 Plain words. Each level in one sentence on the grant screen; no jargon.
  7. R7 Nothing phones home. A plane that cannot reach Qpoint has no grants.
the grant: the one recordthe plane side (c134, engineering with Kamal)ours to build in the native app (c131)Qpoint, outside the partner's planethe partner's people
The problem
Build partners will run their own planes with their own data. When Qpoint needs in, to fix a documented problem, implement a feature or hot-fix an incident, a screen share or a shared credential is exactly the exposure the product removes elsewhere. The categories and levels have to exist before the first plane ships, so a partner can grant with confidence and we never ask for more than the job needs.
The core idea
A grant is a module with a purpose (why) and a protocol (what, for how long, logged how). The partner opens it for a stated reason, at a documented level, for a bounded time, and sees everything done under it, live and at close. Visibility before control: the two honest surfaces say what is true and say nothing when nothing is.
What is open
Where grants live is the plane by default (D1), pending Tyler's say; the plane's identity model (c134 D2) gates Phase 1. Are diagnose · fix · implement · hot-fix the partners' words (ask two before Phase 1)? Does Change need two admins? Does a grant ever reach an endpoint machine (default: no)? The contract line, with Rob, later.

Qpoint Brand Style Guide