The intake method
CIFER
Contextual Isomorphic Forensics Executable Runtime
CIFER is the owner's claims-adjudication method — Contextual Isomorphic Forensics — raised to a systems-level runtime. It reads material from any domain and decides what bears on the problem in front of it by matching structure, not vocabulary.
Base method → executable extension
Contextual Isomorphic Forensics
The reasoning technique: compare apparently unrelated material by mechanism, invariant, failure shape, and workability rather than by topic labels.
Contextual Isomorphic Forensics Executable Runtime
The executable extension: the CIF test becomes a runtime that can audit relevance language, refuse substrate-only rejection, and call an enacted ternary law.
Where the method came from
A general liability claims examiner reads a medical record, a police report, and a repair invoice — three unrelated document types — and extracts what bears on one claim. The claim's structure is the correspondence. The documents' topics never were. CIFER is that practice made executable.
cifer is an expansion on my personal method of cif — it's what allows you to identify topics that might seem unrelated, but allow you to parse what is important or relevant
The mechanism
Recurrence shape, invariant, verdict form, failure class. Two problems that share no vocabulary can share structure, and the correspondence is what carries importance across a domain boundary.
The estate built a token-overlap scorer first and kept its failure. It misrouted six ways: “stand” matched “start” and “land”, so one surviving token scored a perfect match against a sentence about Fibonacci numbers. That run is retained as the negative control.
A hand-written table of correspondence rules can only encode the correspondences its author already knew — which are precisely the ones that needed no detector. Correspondence is therefore measured against cases already held, not against rules written beforehand.
Why it cannot be shipped as a rule table
Every filed instance of the mechanism is retrospective: the correspondence was recognised after both routes had been walked, never predicted from a rule. The consequence is mechanical rather than philosophical — the selector has to be an accreting case ledger whose discriminating power is a function of how many cases it has survived. It is worth little on day one. That is not a defect; it is what “learned by experience” means once you make it machine-readable.
CIFER can't be taught it has to be learned via experience
What CIFER is, adjudicated
An earlier record left open whether CIFER executes on the exact-arithmetic engine, beside it, or is the name for that engine operating at capstone scale. The owner ruled. The ruling was then checked against the sealed record rather than accepted on authority — because a ruling may do many things, but it may not contradict what is already sealed.
yig at floor ten scale which employs side agents and source checkers
Executable, not asserted
The ruling was not accepted on authority. It was written as a program, run on the one admitted interpreter, and its output hashed. Anyone holding the estate can run the same file and compare the digest.
The sealed governance binds each engine to exactly two books, one private and one public — four ledgers for two engines. A third engine would demand six. The doctrine names four. So “CIFER is a separate third engine” is refuted by the sealed ledger count, and “CIFER is the engine at capstone scale” leaves that count untouched. Case 6 is a mutation control: the ledger function must read its argument, or every line above it is vacuous.
Ran on Yig 1.0.0 · 0635500e6db71d4d7be7abf72c3675de…
The two halves
CIF/CIFER selects the domain: what, out of everything available, bears on this problem. ERC/ERCATCH then works that domain: expand the catch, reduce to load-bearing, consolidate one package, gate its assignment, and hand an admitted package toward ternary adjudication. The selector and pipeline are now wired; the final TCH execution remains downstream rather than joined inside ercatch.py.
CIFER ingests and classifies; ERCATCH expands the search, reduces to what survives refusal, consolidates into sealed record, assigns, and adjudicates by ternary heuristic.
Read this against everything above
The runtime establishes that the relevance rule is executable and its guards fire under their controls; it does not establish that every named correspondence is correct.
The four research routes re-ruled on 2026-08-08 remain 0 UNSEARCHED. Naming their possible structures created a duty to inspect them; it did not create findings.
The current checks ran on the estate's own laws and one host. They are not independent review or product qualification.
The useful next reader
The strongest objection to CIFER is a pair of problems that correspond structurally and should not be treated alike. That case would narrow the method, and narrowing it is worth more than agreeing with it.
Enter as a reviewer