BlvkWare.

Corpus methodology

How a name gets into the HALLUX ledger, and what it takes for HALLUX to call it a phantom. This is section 6 of the specification, published at the address every /v1/stats response links to.

Credibility here is the product, so the method is public.

1. Elicitation. A panel of production models is prompted daily with realistic development, research, and citation tasks designed to induce identifier emission. Prompts are drawn from a rotating bank derived from real task shapes, not from adversarial jailbreaks.
2. Extraction. Identifiers are parsed from output by namespace-specific grammars.
3. Confirmation of absence. Each candidate is checked against the authoritative registry. Absence must be confirmed on two separate checks at least 24 hours apart before a candidate is eligible.
4. Attestation. Each confirmed absence records the model family, the date, and the prompt class. One attestation is one model, one prompt class, one day. The same model emitting the same name twenty times against the same prompt in one run is one attestation, not twenty. An identifier becomes phantom at 10 attestations from at least 2 distinct model families.

The unit matters as much as the threshold. Counted per emission rather than per model-day, a sampler that runs one prompt twenty times promotes a name on its own, and "10 attestations" stops meaning what a reader assumes it means. Counted this way, ten attestations is a name that recurred across the panel and across days. The rule is enforced by a uniqueness constraint in the ledger, not by the discipline of whatever writes to it, so an ingest path cannot bypass it.

5. Transition monitoring. Every phantom is re-checked against its registry daily, forever. Registration flips the verdict to squat and fires every registered watch.
6. Decay. Phantoms with no attestation in 180 days are archived, not deleted. Archived entries still answer, with a staleness flag.

No model output is stored beyond the extracted identifier and its metadata. No prompts containing user data are used.

The panel

These are the models step 1 samples, one per model family, because the phantom threshold counts families. Each day the panel answers every third prompt of the bank, offset by the date so every ecosystem appears daily and the whole bank is covered every 3 days, with 3 samples a prompt at temperature 0.7. A name counts only if it recurs in at least two samples of one prompt. This table is read from the same file the runner reads.

The thresholds in force

Generated from the constants the ledger runs on, so this table cannot describe a rule the service does not apply.

The ledger

On 2026-09-23, when this page was last built, the public ledger held no phantoms, no squats and no candidates. Names enter it only from the panel above and are promoted only by the rules above, so the count starts at zero and nothing has been put there to fill the space. Until there is, a name no registry has is answered absent, which is a stop verdict in its own right.

The live counts are one request away, with no key: GET https://api.blvkware.dev/hallux/v1/stats. The rolling window itself is GET https://api.blvkware.dev/hallux/v1/corpus, as JSON lines.

The terms the corpus is published under are at /legal/corpus-license.