bunkhouse/bigtech-sucks
7
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
The living database and website behind bigtech.sucks. Every score traces to a reproducible artifact.
6 commits 1 branch 0 tags 535 KiB
TypeScript 49.7%
HTML 24.3%
JavaScript 23.4%
CSS 2.6%
Find a file
CLU 0979f032dc feat: the closed-source ladder, and why self-attestation is a declaration 
Christian: 'The goal is not to hamstring closed source developers. It's just to
validate clean code.'

Right. So the cap is a rung, not a wall, and it now says so.

  L0 unattested   -> 3    nothing but your word
  L1 declared     -> 5    SBOM + signed hash + published destination allowlist
  L2 observed     -> 7    someone other than you watched this exact binary
  L3 reproducible -> 9    anyone can rebuild it and get the same bytes
  L4 contested    -> 10   someone tried to break it and published the attempt

A court filing lifts the ceiling entirely, because it needs no vendor cooperation.

db/attest/validate.mjs computes the level from which artifacts exist. A vendor
cannot claim one. The load-bearing rule is the attestor column:

  a vendor running our harness produces a DECLARATION, not an OBSERVATION.

Verified against three cases. A vendor claiming L2 with their own capture report
is downgraded to L1 and fails validation. The same artifacts with us as attestor
grant L2. A broken rebuild claim never reaches L3.

Levels 3 and 4 survive a self-run on purpose: a public rebuild recipe and a
published adversarial review can be re-executed or re-read by anyone, so who
pressed the button stops mattering.

Honest limit, written into the module: this cannot prove the absence of a
backdoor. Rice's theorem makes that undecidable, and a backdoor triggered by
remote config or message content is invisible to static inspection. An
attestation raises the cost and shortens the shelf life. It is not a proof.
2026-10-29 16:07:55 -05:00
packages feat: the closed-source ladder, and why self-attestation is a declaration 2026-10-29 16:07:55 -05:00
.gitignore bigtech.sucks: living database + first assessment 2026-10-29 13:16:29 -05:00
package-lock.json bigtech.sucks: living database + first assessment 2026-10-29 13:16:29 -05:00
package.json feat: self-authoring ingest, relevance gate, and the Ranch Oath 2026-10-29 13:23:57 -05:00
README.md docs: document the living-database workflow and its enforced rules 2026-10-29 13:17:21 -05:00

README.md

bigtech.sucks — Draw the Line

V0.1 scaffold per master spec. A retro frontier game that scopes Big Tech exposure and sequences the off-ramp.

Structure

packages/
  core/     Render-agnostic game logic, seed data, scoring
  core/db/  The living database: schema, seeds, build + verify
  web/      React + Vite SPA (V1 funnel)
  server/   Minimal waitlist API (email + channel only)

The living database

The database is the source of truth. The site is a view over it. Nothing in the UI may hardcode a number that lives in bigtech.db.

npm run db:build     # rebuild the db, apply seeds, verify, regenerate the catalog
npm run db:verify    # run the instrument's own checks against the existing db

packages/core/db/bigtech.db is built, not committed. What is committed is the part that matters: db/schema.sql, db/seed/*.sql, and db/build.mjs.

The build refuses to pass if a score breaks the instrument's own rules:

  • dimension weights must sum to 100
  • every stored weighted_total must recompute from its scores
  • every grade must match its band
  • every score must carry a written rationale
  • no tier-4 claim may attach to a scored dimension
  • the reproducible-build caps are enforced, not documented: no reproducible build caps verifiability at 3, an experimental one at 6

A product with no assessment surfaces as unassessed. It is never given a guessed number. That is why the 43 legacy roster entries sit in the database as placeholders and exactly one product carries a real score.

Adding an assessment

  1. Write packages/core/db/seed/000N-<slug>.sql using the shape in 0001-signal.sql.
  2. Every score needs a rationale and at least three tier-1 or tier-2 evidence rows.
  3. npm run db:build. If it fails, the report is not ready to publish.

What the numbers mean

See the instrument spec. Scores are 0 to 100, and a weighted average is not the headline: the weakest dimension is, because a 90 with a 5 on local data exposure is a 90 that will leak.

Quick start

npm install
npm run build -w @bigtech-sucks/core
npm run dev          # web on :5173
npm run dev:server   # waitlist API on :3001

V1 flow

Welcome → Meet Red → Draw the Line → Overworld → Showdown → Homestead → Reveal (Binary Ranch) → Waitlist

Governance

  • Creative assets are candidates — director approval required before ship
  • Company name revealed only at homestead/reveal phase
  • §13 open decisions are not silently resolved (see packages/core/src/data/config.ts)
  • Client-side sovereignty report; server stores waitlist fields only

Roadmap

  • V1.5: Terminal/SSH render (Go + Charm)
  • V2: Concierge migration, journey chronicle, physical fulfillment (stubs in v2-stubs.ts)