Mechanic Access

Build partners will run their own planes with their own data. When Qpoint needs in, a screen share or a shared credential is exactly the exposure the product removes elsewhere. Mark's framing on 2026-11-09: the partner opens access for a stated reason, at a documented level, for a bounded time, and sees everything done under it. Specifying the categories and levels before the first plane ships lets partners grant with confidence and keeps us from asking for more than the job needs. The brand's guardian "you don't have to think about" applies to our own access too.

Sketch: A grant and its five states, drawn 2026-11-10 in the design system; Mark's own drawings may replace it.

Done means: the grant model (purpose, level, scope, window, who, record) written as data with plain-language sentences; the grant screen and active-grant states mocked in the lab and the Status line as a native story; the routes and access.grant.* events agreed with Tyler and Kamal and added to c134's API document; one partner-facing page; the hand-off to c134 and c131 recorded here.

• Cycle docs: cycles/c136.mechanic-access/ (plan.md, prior-art.md, thread prompt/plan pairs)
• Design site: the grant flow mocked in the phase-4 lab inside c134's shell
• Sister projects: ../qnative (a Status story), the control-plane repo once it exists (the plane side, via c134)
• Out: access to endpoint machines (plane only by default); partner-to-partner grants (noted, not built); contract language (Rob, later)

• stage 1 (2026-11-09): created from Mark's ruling on c130 D6 during the decisions walk. initial-prompt.md quotes his words; plan.md proposes four purposes, three levels, seven rules and seven defaults. CYCLE.md written before kick-off at Mark's request (c130 clarifying question 6).
• 2026-11-09, later: Mark confirmed D1–D7. Committed the same day.
• sketch and story (2026-11-10): the grant sketch (app/pages/cycles/design/sketches/c136-grant.vue, captured as c136-sketch-grant.png), the story module (app/data/stories/c136.ts, D1–D7 as decisions, the sketch as hero) and this record's sketch line and "The shape" section.
• Phase 0 (2026-11-11): prior-art.md reads seven precedents (AWS support roles and sessions, Google Access Transparency and Access Approval, Azure Customer Lockbox, GitHub App installs, Tailscale, break-glass and JIT elevation, Okta and Salesforce support grants with Kolide for the words) against the four purposes, three levels, seven-day window, named people and the single event family. We copy the structured reason plus the partner's sentence, the request that pre-fills the grant, the session under the grant, permissions as sentences and the expiry said at the moment of grant; we refuse standing roles, unnamed or impersonated actors, unrevocable approvals, break-glass around the grant and a year-long window. Thirteen questions with defaults (the plan's four plus nine the reading raised) wait for Tyler and two partners.

Not started.

Documents: the plan · Mark's prompt · prior art (Phase 0, 2026-11-11)

The problem. Build partners will run their own planes with their own data, and Qpoint will need in: to diagnose, to fix a documented problem, to implement a feature, to hot-fix an incident. Without a design that is a screen share or a shared credential, the exposure the product removes elsewhere.

The core idea. A grant is one record on the plane (purpose, level, scope, window, who, record), opened by the partner for a stated reason, at a documented level, for a bounded time; every grant ends. Visibility before control: the partner sees what is done under it, live and at close; the endpoint shows one honest line and nothing when there is none.

The pieces.

• The grant and its five states (none · requested · active · revoked · closed with summary): plan.md §The shape; written as data in Phase 1.
• The four purposes and three levels, each said in one sentence (R6): plan.md; adding one is a cycle decision, not a configuration (D6).
• The rules R1–R7: plan.md §Rules.
• The grant screen and the active-grant states: the phase-4 lab in c134's shell (Phase 2); the plane side itself via c134 (D1).
• The Status line: a c131 story in ../qnative, read-only (D7).
• The audit record: the access.grant.* event family (D5), agreed with Tyler and Kamal and added to c134's API document (Phase 3); the opening notice travels as a c137 message.
• The sketch: /cycles/design/sketches/c136-grant and its capture, the story's hero.

The pattern we follow. A grant is a module with a purpose and a protocol: the partner does not need to know how our mechanic works, only what they let in, for how long, logged how. Visibility before control. Formula first (support roles, break-glass, Access Transparency, permissions as sentences), then assemblage: the grant is composed from the plane's identity, the audit log and the native app's Status line.

What stays open. Where grants live (Tyler; the plane by default); the plane's identity model (c134 D2) gates Phase 1; whether the four purposes are the partners' words (ask two); whether Change needs two admins; whether a grant ever reaches an endpoint machine; the contract line, with Rob.