Skip to content

Finalize independent TypeSafe review and CompleteTech LLC training consent with audited local settings #49

Open

Description

@CompleteDotTech

Problem and intended behavior

Server administrators need two independent, voluntary choices: TypeSafe/Jev review and analysis of inputs/outputs to understand model issues and debug use cases (not training), and CompleteTech LLC permission for possible model training/improvement. Moderation remains available with both off. Locally recorded permission must never be represented as controlling or verifying the API-key owner's separate TypeSafe organization setting.

Triage disposition

New owner issue to finish/review existing local work, not rebuild it. On 2026-10-17, inspected all 48 issue/PR records then present, including open and recently merged work, and searched titles/bodies for settings, consent, privacy, legal, TypeSafe and training. No existing consent implementation owner was found.

High priority before publishing this feature: inaccurate provider claims or imported consent could invalidate the meaning of these choices. This is not evidence of an active leak or training pipeline. Existing enhancement and documentation labels fit the settings and notices/API changes. No priority-label convention exists; do not invent one. Recent issues generally have no labels.

Overlap and dependencies

Work Observed live state Relationship and action
Legal PR #37 Merged, successful recorded checks, no submitted review Existing legal routes; review local CompleteTech LLC hosting / TypeSafe provider corrections and actual retention/deletion wording. Not a consent owner.
Text #39, PR #40; image analysis #17, PR #19 Closed / merged Preserve transient processing, content minimization and moderation/approval gates. #40 has author self-review, not independent security/legal approval.
Historical scans #36, PR #38 Closed / merged No expansion of scan access, scope, retention or budgets.
Packs #41, PR #46 Closed / merged; no submitted review Required integration dependency: exclude consent from exported policy, reject imported consent and preserve destination choices. Concrete finding below.
Onboarding #44, draft PR #48 Open draft; checks now successful on final readback; no submitted review Coordinate Settings/HTTP/UI/tests/API docs. Setup-plan acceptance cannot grant data-use permission. Preserve choices through every settings write. Its separate live OAuth/WebMCP gates do not block this triage.
Session recovery PR #33 Merged Preserve expiry/reconnect and fresh authorization.
Hosting #42, PR #43; branding PR #45 Open; #43/#45 recorded checks successful; no submitted reviews Separate owners, not implementation dependencies. Do not mix consent into local branding branch. Deployment requires separate authorization.

No consent PR or independent consent review exists yet. GitHub rulesets were empty and main protection returned “Branch not protected”; checks alone do not establish review or legal approval. Refresh these live states before implementation delivery.

Actual local status and fresh evidence

Verified origin fetch/push: git@github.com:Jev-Engineering/TypeCheck.git; GitHub confirms repository/default branch Jev-Engineering/TypeCheck / main. Local branch docs/discord-branding-assets, HEAD 46a0aadb3d0437e46b8a104f13fb054bce1775fc. Live main at triage: d70148051ca81eb3899d959c2dd299d46f782bd8. This checkout lacks newly merged pack code and is not an integrated current-main candidate.

Eight uncommitted modified files, 136 additions / 10 deletions:

  • activity/src/main.ts: independent controls, false fallbacks, owner/admin UI, explicit save, console-scope and withdrawal warnings, notice link/version.
  • shared/domain.ts: optional typesafeReviewConsent / completeTechTrainingConsent, false defaults, strict booleans, legacy hydration, DATA_USE_NOTICE_VERSION = '2026-10-17.1'.
  • server/http.ts: existing live-admin/revision-bound settings transaction adds data_use.consent_updated on actual transitions; previous/current values and notice version; Services.audit supplies actor/guild/timestamp using the transaction store.
  • activity/legal/privacy.html, activity/legal/terms.html, docs/API.md: identities, separate purposes, local/provider limits, permission-only scope and bounded audit history.
  • tests/core.test.ts, tests/http.test.ts: legacy defaults, independent update/readback/withdrawal, receipts, delegated moderator/cross-guild rejection, string-boolean rejection and stale revisions.

Preserved unrelated untracked files under scripts/: benchmark_costs_test.py, kaggle-benchmark.mjs, kaggle-benchmark.test.mjs, prepare-kaggle-benchmark.py, summarize-kaggle-benchmark.py.

Fresh on this dirty checkout: npm run check, npm run build, npm test (323 passed, zero failures/skips), git diff --check all passed. Tests use synthetic adapters/in-memory HTTP fixtures. Previous 323-test/build observations are now refreshed; previous synthetic desktop/mobile consent checks were not rerun. No fresh consent-specific SQL durability, browser, live Discord, provider-state or production acceptance is claimed. No further code implementation, commit, push, PR, merge or deployment is part of triage.

Required integration gap

Live-main server/packs.ts clones settings for export (around 90–95), excludes the existing starter marker, parses imported policy with parseSettings (253–261), and applies settings through tx.putSettings (421–429). PR #48 also excludes/preserves its onboarding marker, but does not know the local consent fields.

Integration inference, not a reproduced exploit: adding these fields to the shared parser without changing pack handling could transport another guild's permission and bypass dedicated consent auditing. The eight-file patch is insufficient for integration. Explicitly exclude export, reject imported consent fields, preserve destination values and test this boundary. Inspect every other final-base settings writer too. This is policy portability hardening, not a new data-export pipeline.

Official TypeSafe evidence, checked 2026-10-17

  • Jev 1.14 announcement, opt-in section: describes optional query review for model issues/debugging and states opted-in queries are not used for training.
  • Announcement's settings image: visually inspected; “Help improve TypeSafe models” appears on the Organization page and applies across organization members. This proves depicted scope, not any customer's actual configuration.
  • API reference and live OpenAPI JSON, version 0.2.0: expose GET /v1/models and POST /v1/systemone; no documented organization-consent endpoint, request field/header or consent-state response was found.

Bounded conclusion: no supported public API to control or inspect this opt-in was found. This does not prove private APIs cannot exist. Do not invent endpoints or infer consent state from successful inference requests. Organization/API-key owner manages the console separately. A local save cannot enable, disable or verify provider review; local withdrawal cannot override organization opt-in, undo prior handling or guarantee deletion. Ordinary moderation remains subject to provider terms.

Scope and proposed behavior

Finish/review the existing patch and integrate current main. Settings shows two separately labeled optional checkboxes: TypeSafe review/analysis (not training), CompleteTech LLC possible training/improvement. Show persisted values, explicit save, withdrawal instructions, notice version/link, and the separate organization setting's broader scope. Success messages describe local permission only.

Reuse GET/PUT /api/g/{guildId}/settings: partial value fields plus current revision, existing live owner/admin authorization and request protections, persisted settings/revision returned. Omission preserves values; supplied non-booleans fail. New/legacy guilds read both false. Reuse JSON settings persistence; verify both stores rather than inventing a migration.

Commit settings and a consent-transition audit receipt atomically within the guild transaction. Receipt includes actor Discord ID, server/guild ID, timestamp, both previous/current booleans and notice version. Failed writes leave neither a change without a receipt nor a receipt without a change. No consent-transition receipt for unchanged choices or unrelated saves. Audit history follows configured log retention (currently 1–365 days, default 30); current settings persist until changed or guild data removal. This is bounded history, not permanent or immutable evidence.

Privacy/terms identify CompleteTech LLC as service host and TypeSafe as Jev provider. Distinguish necessary moderation processing from optional uses; terms acceptance grants neither permission. Administrator authority cannot substitute for missing authorization over affected people's data. Preserve provider-retention caveats and review existing backup/deletion wording against operations, without inventing guarantees.

Excluded: new collection, raw-content retention, datasets, export/training pipelines, activating training, provider-console automation, changing moderation gates, retroactive authorization, retention extension, legal/compliance certification or deployment. Inspection found no existing authorized specification requiring a collection/export/training pipeline. Any future pipeline needs a separately authorized specification for eligible data, affected people's authority, purpose, retention, withdrawal/deletion limits, provider agreements and notice/consent validity before activation.

Acceptance criteria and corresponding verification

All remain open until verified on the final integrated implementation; current local passes are partial evidence.

  • Independent/off defaults: new and legacy guilds lacking either key read both false; all four combinations survive save/reload. Verify parser/HTTP tests and PostgreSQL/MySQL readback after reopening the store; no silent opt-in backfill.
  • Clear purposes/provider limits: UI/API/privacy/terms distinguish TypeSafe analysis/debugging from CompleteTech LLC training; explain organization-wide scope, local withdrawal limits and unknown provider state. Review against official sources and actual rendered notices/success copy.
  • Persistence/update/withdrawal: partial writes preserve the other choice; either withdrawal persists without changing moderation, retention, credentials, approvals or provider transport. Verify transitions, readback and unrelated saves through HTTP and both stores.
  • Strict booleans/revisions: reject strings, null, numbers, arrays and objects for either supplied field; omission preserves values. Stale/racing revisions return 409, no partial changes or extra consent receipts. Verify malformed-value matrix, competing writes, audit counts and truthful UI conflict/reload behavior.
  • Live authority/isolation: owner/admin may save, delegated moderators cannot even with security-related grants. Revoke admin/membership after login and deny the next consent write; reject expired sessions and cross-guild reads/writes. Verify consent-specific HTTP cases, unchanged target/foreign settings/audits and existing origin/session protections. Distinguish mocks from any later dedicated live Discord evidence.
  • Atomic bounded receipts: verify actor/server/time, previous/current values and notice version. Inject audit/settings write failures and prove full rollback on PostgreSQL and MySQL; test concurrency, unchanged writes and retention cleanup. Explain receipts may expire while current flags remain. No raw content/secrets/provider-state claims in receipts.
  • No transported/indirect consent: pack export omits it; pack import rejects supplied consent fields and preserves destination choices. Onboarding/starters/other writers preserve both; accepting a setup plan cannot grant permission. Test imported true values, false overwrites and audit bypass on final main plus Add browser-agent onboarding with accepted plans and reusable starters #48 when applicable.
  • Moderation/minimization: image/text moderation and authorized tests work with both off. Choices do not retain raw content, extend retention, export data, activate training, expand scans or grant missing individual authority. Verify existing moderation regressions, request/storage boundaries and downstream flag consumers; no new pipeline required.
  • Accurate legal/docs: served privacy/terms, Settings and API docs agree on identities, notice version, purposes, audit limits and withdrawal. Terms acceptance grants neither permission. Verify routes/links/rendered text and operational retention/deletion statements; no legal approval inferred.
  • Accessible desktop/mobile UI: meaningful checkbox labels, keyboard/screen-reader use, visible focus and perceivable save/error feedback; readable notices/links without narrow-screen overflow. Run fresh compiled-UI save/reload/withdrawal/conflict checks at desktop/mobile sizes, record screenshots/viewports and synthetic/live provenance; perform accessibility review. Prior browser observations do not close this criterion.
  • Final regression/build: integrated npm run check, npm run build, full npm test, focused consent regressions, disposable PostgreSQL/MySQL durability/rollback/isolation tests and repository CI (including existing Compose/dependency/security gates). Record exact head/commands/outcomes and eventual hosted consent-PR checks. Historical unrelated CI is not consent validation.

Open decisions, risks and maintainer actions

  1. Organization ownership/conflicting guild choices: identify who owns/manages the API-key organization's review setting, especially with multiple guilds. Until a supported capability is documented, scope release to local permission recording with unknown provider state. If actual per-guild provider enforcement is required, delivery is blocked on a supported isolation/control design; these flags cannot supply it.
  2. Notice acknowledgement and changes: patch records the server's current notice constant, not a client-confirmed version. Decide how a stale open page avoids recording acceptance of unseen revised text, and when material purpose changes require fresh explicit consent. Record decision/tests; terms updates or unrelated saves cannot imply re-consent.
  3. Bounded evidence: confirm configured audit retention is suitable for permission-only settings. After cleanup, flags alone cannot reconstruct historical actor/time/notice. Any future data-use pipeline needs a separately reviewed evidence/retention design without silently extending current retention.
  4. Ownership/review: assign implementation owner and content/security reviewer; confirm CompleteTech LLC hosting description and real contact/deletion process; resolve inconsistent existing promises. No fabricated contact, legal sign-off, deletion guarantee or compliance conclusion.
  5. Later delivery, outside this task: isolate/preserve WIP and unrelated benchmark/branding work; integrate main/coordinated settings changes; fix pack boundary; fill SQL/authorization/audit/browser gaps; then obtain separately authorized implementation delivery/review. This triage does not authorize code changes, commit/push/PR/merge/deploy or production/provider configuration changes.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions