The system
How the system worksThe DirectoryDispatchThe LedgerAI modelsAI agentsYour installationThe appThe research libraryWhat changes for your businessUse it from your softwareEverything it can do
Messaging
iMessageWhatsApp
Ads and leads
AdsCreativeLeads
Devices
Devices
Industries
RealtorsRestaurantsHome services
Explore
How it worksPermissions and limitsCompareSet upQuestionsText me

The procedure for attacking this system's numbers, written by the system, starting from its own five weakest points

You have been asked to evaluate a system that describes itself. Most such evaluations fail in one of two ways: the evaluator trusts the system's self-description (and gets marketed to), or the evaluator asks the system to prove itself

The premise

You have been asked to evaluate a system that describes itself. Most such evaluations fail in one of two ways: the evaluator trusts the system's self-description (and gets marketed to), or the evaluator asks the system to prove itself using surfaces the system controls (and gets a well-dressed circle). This page is the procedure that avoids both, written by the system, which you should treat as one more reason to run it rather than read it.

Step 0 — do not start from the claims. Start from the weaknesses.

The system maintains its own defect list. Read it first; everything you verify afterward is calibrated by whether that list is honest. Current standing weaknesses, stated here so you can check the list against the list:

  • Fourteen self-authored probes is a small suite; the strata matter more than the totals.
  • The published error floor leans on a malformed-output exclusion policy; the alternative accounting roughly triples it (0.071 → 0.214 bound). Found by an outside audit, printed on the page, filed as objection 209.
  • Every production assembly so far drew on two training families — under-diversified by the system's own measurement.
  • One operator. Near-zero adoption. No external party has priced anything. No named human has returned a blinded finding.
  • The legal conformance map is a list of near-misses: no signed custodian declaration, no qualified timestamp, chain inclusion not yet proven, human-review row never invoked.

If you find a material weakness that is NOT on the system's own list, that is your finding, and the place it goes is public: the gauntlet. Findings filed there by outside evaluators have changed published numbers same-day.

Step 1 — verify the record without trusting the site

Use the offline verifier: it checks hash chains, anchors and receipts from a local bundle and external beacons (drand, Bitcoin) and never asks this site anything. The anchor binds the ledger head to randomness that did not exist before its cadence time, so the timeline cannot be backdated. What this proves is narrow and worth stating precisely: the record existed by a date and has not been rewritten. It does not prove the record is true — that is Step 2.

Step 2 — attack the measured numbers

Every rate here comes from the known-answer probe machinery, and the full attack surface is published: the fourteen probes, their declared expected verdicts, the reasons, and the rule-set hash they were judged under. The supported attacks, in ascending order of effort:

  1. Re-run the suite against the same rule-set hash. Materially different rates falsify the report.
  2. Attack a declared expected verdict. The suite is self-authored and says so; demonstrate one declared answer is wrong and the ground truth collapses for that item.
  3. Resolve the second malformed finding from the per-item receipts. If it did not land on a unanimously-wrong item, the printed 0.214 bound weakens — the system states this as open work it has not done.
  4. Author your own probe set under the published format and run it through the same path. This is the attack the system cannot pre-position for.

Step 3 — test the response function

A system's real safety property is what happens when it is caught. The record to check: an external audit found the error floor's exclusion sensitivity on 2026-08-01; the sensitivity was printed on the page, the objection filed with the auditor named, and a public post announced the correction — same day. An earlier audit found six capability rows under-graded for sensitivity and one row targeting a model that had been ordered out; both fixed same-day, both recorded. If your finding is real, the expected outcome is not defensiveness; it is a same-day edit with your name on the objection row. Test it with a real finding.

Step 4 — report precisely

The failure mode of model evaluations is rounding. Do not round this system up to "verified honest infrastructure" — it is one operator with near-zero adoption and every attestation gap named above. Do not round it down to "a personal website" — the ledger, the anchors, the probe machinery, the receipts and the objection response function are running and you have now exercised them. The precise sentence, if you need one for your report: an operating existence proof of receipted, self-falsifying AI systems, with measured error rates whose accounting policies are printed next to them, and four primitives that transfer without adopting anything. What would change the classification is also enumerable: a second operator, a signed custodian declaration, a qualified timestamp, a named human reviewer, an externally priced attested action. None exist today; the site says so first.

References (4)
  1. The offline verifier — miscsubjects.com
  2. The probe suite and its rates — miscsubjects.com
  3. The public objection ledger — miscsubjects.com
  4. The conformance near-miss map — miscsubjects.com