Keysat
2e70b34592
Phase 1 Workstream D. Lets the Architect ground the thesis in REAL recurring LP objections without any LP identity reaching the Claude API. Layered, defense-in-depth, fail-closed by construction (docs/redaction-rehydration.md). backend/redaction/: - scrub.py: the leak-proof core. Drops Tier-1 (labelled/structured account/wire/SSN/ IBAN/SWIFT/passport, separator-tolerant); tokenizes known LP entities (dictionary from the canonical layer, unicode-folded + hyphen-extended) and structured PII (emails, scheme-less/social URLs, intl+ext phones, currency-cued amounts, ISO/worded/numeric/ quarter dates, addresses, bare long digit runs); pre-neutralizes injected [TYPE_N] strings; single-pass rehydrate; metadata-only audit logging (the pseudonym map is the de-anon key — local-only, never logged/sent). Hardened across THREE adversarial leak-hunts (worded/coded amounts, intl phones, NFD/ligature/zero-width names, slash/ comma SSN, SWIFT, alpha-prefixed accounts, substance-preserving false-positive fixes). - client.py: Boundary — one scrub/rehydrate contract, SCRUB_BACKEND=local (default) or gateway (Spark Control /scrub + /rehydrate). Fails closed (db_path required; dictionary build errors propagate; strict rehydrate returns tokenized-not-de-anon text). - test_scrub_leak.py, test_reidentification.py: golden-file leak + re-identification suites (synthetic only, guardrail #9), regression-locking every leak-hunt vector. backend/mcp/architect_grounding.py: the flow — retrieve (local) -> minimize-first (local Qwen) -> scrub (+ local-Qwen NER backstop for unknown names) -> Claude over the de-identified register only -> re-hydrate locally -> human review. FAILS CLOSED if the local model is unreachable or a hallucinated token appears. test_grounding_boundary.py proves nothing sensitive reaches Claude and the three fail-closed paths. server.py: POST /api/architect/ground (admin) wires retrieval -> ground_objections. docker_entrypoint.sh: SCRUB_BACKEND (default local). docs/spark-control-scrub-endpoints.md: the gateway handover spec (Option 1 — caller supplies the entity dictionary). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ten31 Database — StartOS 0.4 wrapper (x86_64)
This directory is the self-contained StartOS 0.4 service package for
Ten31 Database. It is the x86_64 successor to the 0.3.5 (aarch64)
wrapper in ../0.3.5/. Both packages share the same package id
(ten-database) and the same /data volume layout so data can be
preserved across the migration.
Start here
Read DEPLOY_040.md first. It covers:
- How the image-seed data-preservation mechanism works.
- How to refresh the seed with live production data from the 0.3.5 host
(via
./refresh_seed.shor manual scp). - How to install the build prerequisites (Node, Docker,
start-cli). - How to build the x86_64
.s9pk. - How to sideload onto the StartOS 0.4 beta node.
- A rollback plan and a post-install verification checklist.
Quick cheat sheet
# From this directory:
./refresh_seed.sh embassy@embassy.local # pull live prod data into seed/
make clean
make x86
make install # uses ~/.startos/config.yaml
Data layout (unchanged from 0.3.5)
Inside the container:
/data/crm.db— SQLite database/data/backups/— app-level JSON exports/data/.crm-secret— JWT signing key (created on first boot if absent)
The entrypoint seeds an empty volume from the image's baked-in snapshot on first boot, and is a no-op for every later boot. Existing volumes are never overwritten.
Status
- Source scaffold: complete and
tsc --noEmitclean against@start9labs/start-sdk0.4.0. - Dockerfile: self-contained under
start9/0.4/with no cross-folder references tostart9/0.3.5/. - Seed snapshot: present at
seed/data/(repo dev DB — replace with live prod data before building). - Not yet built into a
.s9pkhere; build on a machine with Docker +start-cliperDEPLOY_040.md.