keating/ developers

Platform / HANDBOOK

Data, privacy, and authority

Understand what is saved, where credentials belong, and how an export differs from consent to share.

Store by lifetime and authority

Keating distinguishes UI bootstrap values, app records, and learning records. Small preferences needed before hydration belong in localStorage. Sessions and durable app settings use an app-storage abstraction; learner evidence, goals, reviews, quizzes, and generated artifacts use the learning-record layer.

Each record has one authoritative backend. Feature code should use the relevant storage abstraction instead of opening IndexedDB or independently writing both local and remote copies. Portable export formats have their own versions, separate from database migration versions.

Account authority stays outside the runner

Not Organic supplies the account authority boundary. Authenticated sessions determine the account namespace; a client-selected account identifier is not authorization. The architecture uses PKCE and DPoP for relevant device flows, and keeps account-wide revisions, jobs, and activation authority outside replaceable execution providers.

A runner should receive a job-scoped lease and named capabilities, not account credentials. Provider-specific provisioning belongs in adapters. Account login, durable storage, remote runner dispatch, and successful revision activation each require their own integration evidence.

Credentials follow the host's security boundary

Desktop stores provider credentials in an encrypted vault when a system keyring is available. When it is unavailable, new credentials remain in main-process memory until the app quits; the UI exposes that storage mode. Mobile provider keys use SecureStore. Browser provider configuration follows its device storage adapter.

Never include provider keys in learner exports, analytics, generated teaching artifacts, or browser build variables intended for server secrets. An OAuth callback is only one step: state verification, token exchange, capability checks, expiry, and sign-out are part of the complete flow.

Training archives preserve provenance

Training records identify their source, task, split, messages, completion, and quality status. Accepted, unscored, review, rejected, and reference states are distinct; a generated example is not automatically recommended for supervised fine-tuning. Manifests record export configuration, counts, redaction, and optional judging information.

Building or downloading an archive does not share it. The sharing endpoint requires explicit consent for the selected archive, a server-validated account capability, validated ZIP contents, and configured durable private storage. It does not start a training job or expose public archive downloads. Production collection also needs retention, deletion, and access procedures.

Analytics must stay separate from lesson content

The web analytics adapter centralizes PostHog initialization, preference handling, Do Not Track behavior, and event sanitization. Session replay is separately controlled and masks inputs and text. Replay request sanitization excludes request bodies and headers.

New events should describe a product action using bounded metadata, not copy learner answers, conversation content, account tokens, or provider keys. Instrumentation tests should exercise opt-out and sanitization behavior as well as the successful capture path.

← All documentationSuggest a correction ↗