Sovereignware The sovereign AI operating system · archive of record

Home / Policy / Methodology

Methodology

How Sovereign Beacon™ ratings are produced, version v2.0.

What a Beacon rating is

A Sovereign Beacon™ rating is an editorial assessment of a hardware product, application, website, AI tool, or privacy law's privacy posture, expressed on a four-state scale (Sovereign · Clear · Warning · Critical). It is an opinion formed from publicly available reporting, regulatory filings, vendor disclosures, and academic work. It is not a statement of intent or a legal finding.

Each weekly batch publishes two ratings per category: two hardware products, two apps, two sites, two AI applications, and two privacy laws — paired so that each category includes one Threat verdict and one Secure verdict. Laws are rated by the same standard as products: Secure when they advance individual privacy (GDPR, state shield laws, end-to-end encryption protections), Threat when they erode it (mandatory backdoor bills, warrantless surveillance reauthorizations, age-verification mandates).

How ratings are produced

  1. Reconnaissance. A grounded LLM agent (Google Gemini 2.5 with Search grounding, or Vertex AI in the same configuration) is asked to identify privacy threats and privacy-respecting alternatives across hardware, apps, sites, and AI tools, citing only publicly reported sources from the last 24 months.
  2. Citadel staging. The agent's output is posted through the Embassy Gateway (origin-validated, HMAC-signed) to a local Citadel staging buffer. Nothing is published from staging.
  3. Manual review. The operator reviews each card individually: verifies every cited source resolves, checks that claims match the underlying reporting, and either approves, rejects, or amends the card.
  4. YubiKey-gated commit. Approval requires a physical YubiKey OTP plus master PIN; the approved card is signed by a Marlowe physical core key and committed to the permanent vault.
  5. Publish. Approved cards are mirrored from the vault to this archive as permanent URLs; the latest 20 surface on hectec.org.

Source standards

Beacon-state criteria

The seven-question rubric (v2)

For every subject we rate, we answer these seven questions explicitly. The beacon state falls out of the answers; researcher disagreements are resolved by re-answering the questions, not by debating the tier. This is the same rubric published at hectec.org/methodology.

  1. Who physically holds the data? User's own hardware (sovereign candidate) · vendor cloud, encrypted at rest (clear/warning) · third-party broker or shared analytics (critical).
  2. Is user data used for training, profiling, or ML without explicit per-use consent? Buried-in-the-policy consent counts as yes.
  3. Has a regulator acted in the past 36 months? A $10M+ fine or active investigation pushes to critical; a smaller fine or warning letter pushes to warning.
  4. Is the privacy posture independently verifiable? End-user verifiable via open source + packet capture (sovereign candidate) · third-party auditor only (clear) · "trust us" (warning/critical).
  5. What is the business model? Ads or data brokerage (critical) · user pays (clear/sovereign possible) · open source / non-profit / hardware sale (sovereign candidate) · "free" with hidden extraction (critical).
  6. Is the default configuration safe? Safe out of the box (clear/sovereign) · safe only after configuration (warning) · unsafe regardless (critical).
  7. What is the cloud dependency? Mandatory cloud (cannot exceed clear) · optional / works offline (sovereign candidate) · fully local (sovereign).

Decision logic: any answer pushing toward critical caps the tier at warning; cloud-dependent subjects cannot reach sovereign; an unverifiable answer moves the tier one step more conservative.

Editorial independence

Sovereignware™ accepts no payment, sponsorship, or other consideration from any rated party. HecTec Labs is the editorial author; Sovereignware™ is the canonical archive.

Re-evaluation

Each rating is re-evaluated when (a) the rated party publishes a material policy change, (b) a regulator issues a new finding, (c) a rated party submits a right-of-reply response, or (d) at minimum, every twelve months. Re-evaluation does not delete the prior rating; the archive preserves the chain.