Half or more of what an organisation holds has never been searched, and nobody has read the record of what the AI did with the rest. 132recon surveys both where they sit, finds what's in them completely, and puts every step on the record, without moving or copying anything.
Same tools, two piles. The estate the company has always had, and the pile it started generating the day it turned AI on.
See everything you hold, where it sits. Find any person, clause or record in it, completely, with proof the whole surface was searched. Prove it when a regulator asks. Decide what belongs in the lake, in front of a model, or off the bill.
The model as a binary, not Python, not a wrapper, no MCP, no added attack surface, running inside a rung it cannot reach out of. Then the logs nobody reads: what the models read, what they produced, what repeats, and what it cost. The record you can show when the AI Act asks.
Every engagement runs in this order. Each step is a separate binary; you use the ones the problem needs.
Survey the whole estate where it sits. Three passes: what's there, what it is, what it contains.
Define what to look for, route to it, and search closed-world: every item in scope, a negative is a finding.
Seal the record so any party can verify what was searched, found, decided or produced, without being given the data.
Run each step bounded and stateless, like a rung on a PLC ladder. The check can't be skipped. The model keeps its capability and loses its reach.
The code is the same in all four. What changes is where it sits and who touches the network. Your data stays your data in every case.
Mail, shares, archives, exports, the drives of people who left. It was never worth the cost of making it searchable, so nobody looked, and nobody knows what is there. Recon surveys it where it sits, three passes, nothing moved, nothing copied, and produces a map of the whole estate. In days.
Each pass is a deliverable on its own. Recon 0 and 1 are fast; Recon 2 is the heavy one. Read them as what they tell you, or as the artifact each one writes.
{
"surface": "finance-share-01",
"total_files": 12418,
"total_dirs": 403,
"file_types": { "pdf": 3102, "xlsx": 2210, "docx": 1876,
"msg": 2937, "csv": 611, "png": 940, "other": 742 },
"last_modified": { "≤1y": 1.2, "1–5y": 41.7, "5–10y": 38.1, ">10y": 19.0 },
"owners_present": 3,
"owners_departed": 11,
"largest_dirs": [ "Archive/2014", "Contracts/", "Exports/legacy-crm" ]
}{
"path": "Contracts/2016/supplier-msa-v3.pdf",
"file_type": "pdf",
"honesty": { "coverage": 1, "dark": false,
"ocr_required": false, "source": "exact" },
"blocks": [
{ "block_type": "section", "name": "Term and renewal",
"line_start": 44, "line_end": 61,
"refs": ["38cc…4419"],
"content": "This Agreement renews automatically for successive
twelve-month periods unless either party gives…" },
{ "block_type": "table", "name": "Schedule B, rates",
"line_start": 118, "line_end": 140, "refs": ["cfa0…2391"] }
]
}Every scan is independent, so a large estate is worked in stages and each batch is searchable the moment it lands.
A regional finance manager left eighteen months ago. Her share is still there: twelve thousand files across four hundred directories, migrated twice, never opened. IT wants to decommission it. Legal isn't sure. Nobody can say what's in it, so nothing happens.
The sandbox demo for this page is scheduled in the build phase. The slot is here so the page shape is final.
What exists. What's stale. What's duplicated, and which copy is current. What's not needed. What it's costing.
Compliance exposure. Legal obligations. The nuggets. What a model can read today and what needs OCR.
Off the bill. Into the lake, only what earned it. In front of AI, what good data makes possible. The savings found fund the work.
What was surveyed, when, and what wasn't seen, sealed so any party can verify it later without being given the data. Optional, priced separately, always available.
Recon draws the map. Seek Map says what to look for, a name, a file, the content inside a file. Route takes the search to the right files and folders on that map. Search finds it, completely: every item in scope, so a negative is a finding and the same search runs the same way next quarter.
Search that only knows the defined form finds a fraction of her and reports it as all of her. Seek Map is closed-world on what it's told, the right discipline for a controlled workflow, so something has to be responsible for closing the gap on what it's told.
Closes the gap. Starts from the name and finds the forms she actually takes in this company's data: the old address, the initials in a spreadsheet column, the maiden name on a contract, the French spelling in Paris mail. Adds them to the definition.
Runs the definition. Every surface, every item in scope, the same way every time, and writes what it did and didn't see. This is what lets a search sit inside a rung and be replayed.
Route reads the map and picks the extraction path for each shape, so the search sees the same content whether it came from a scanned page or a database row, and reaches it at the source, not in a copy.
Read the three as what they do, or as the artifacts that cross between them.
subject: "Mary Doe" resolved: # dynamic pass closed the gap on what needed searching - "Mary Doe" - "M. Doe" - "mdoe@oldco.example" - "Mary Doe-Harrison" - "MD" (sheet cols) - "Marie Doe" (FR mail) surfaces: [ mail-2012-2026, finance-share-01, hr-archive, crm-export ] depth: complete # every item in scope is evaluated match: exact | variant # no similarity, no ranking mode: deterministic # same spec, same result, next quarter
{
"query": "seek/mary-doe-v3",
"scope": { "surfaces": 4, "items_in_scope": 1948231,
"items_evaluated": 1948231 },
"found": 312,
"by_form": { "Mary Doe": 201, "mdoe@oldco.example": 74,
"M. Doe": 22, "MD": 9, "Marie Doe": 6 },
"not_seen": { "dark": 0, "ocr_pending": 41 },
"statement": "Every item in scope was evaluated. 41 items are
scanned images pending OCR and are listed, not skipped.",
"hash": "b71e…09c4"
}Every search is closed-world within its scope. What changes is how far it has to go, and that is set by the condition of the data.
A subject access request arrives for a former customer. The last one was answered from the CRM and signed as complete. This time legal wants to know it actually is: every occurrence across fourteen years of mail, three file shares, an HR archive and a legacy CRM export, and something to show if the answer is challenged.
The sandbox demo for this page is scheduled in the build phase. The slot is here so the page shape is final.
Every query and its result, the spec, the scope statement, the occurrences, the hash, sealed as an entry. Any party can verify the search happened as stated without being given the data. Optional, priced separately, always available.
The at-scale search. Billions to trillions of payment or transaction records, and either a confirmed hit or a mathematically guaranteed negative, in a fraction of a second, on your own infrastructure. The closed-world discipline of Data GPS at record-set scale.
Financial institutions, fintechs, and blockchain operators all face the same challenge, they need fast, evidence-grade answers about transactions. Probabilities are not enough.
Fraud and AML checks must happen before or at the moment of transaction. Slow lookups and uncertain results disrupt payment flows and erode user trust. You need a result fast enough to act on.
Regulators and auditors don't accept "probably not there." Dispute resolution, compliance reporting, and reconciliation all require evidence-grade results, not statistical estimates.
Blockchain payment data is high-volume, fast-moving, and difficult to query at scale. Existing tools either can't keep up or weren't built for the demands of digital asset compliance.
Every query returns one of two outcomes, scoped to your available records. Read it as a business process or a technical spec, the guarantee is the same either way.
These are examples, not a definitive list. If your workflow involves transaction verification at any stage, there is likely a fit worth discussing.
Query wallet history and transaction size frequency before a payment clears. Understand whether an account appears in flagged records, fast enough to act on.
Check transaction size patterns and counterparty history before processing. Identify unusual interactions within ingested records without raw data storage or transmission.
When a payment is disputed, establish definitively whether it appears in the record set. A confirmed negative within scope is a defensible, documented result.
The system can coordinate permissioned access, time-limited, query-limited, or email-gated, programmatically. One example of what 132recon can manage beyond direct queries.
The confirmed negative, mathematically bounded within the ingested record set, provides a grounded, loggable result that audit teams can present as evidence.
Query large datasets at constant time without significant query infrastructure. Compatible with existing reconciliation workflows, deployed on your infrastructure.
Verify counterparty transaction history within available records. Understand frequency patterns and amount distributions without building a separate intelligence stack.
Build evidence trails that support regulatory submissions. Each result is loggable and reproducible, with a clear scope statement documenting what the guarantee covers.
Query on-chain payment records at O(1) speed without full-node overhead. XRPL-native, with the architecture to extend to other ledger data depending on what records are ingested.
Integrate into deposit, withdrawal, and transfer screening workflows. Deployed on your infrastructure, against your ingested records, data stays within your environment.
Crypto asset service providers need to demonstrate transaction traceability to regulators. Verifiable, scoped query results deployed in your environment, on your records.
Independently deployable, no third-party dependency. Query the records the protocol has access to, with bounded error guarantees on frequency analysis.
MiCA is in full effect. Crypto asset service providers across the EU face real obligations around transaction traceability, record keeping, and AML compliance.
The confirmed negative is scoped to the ingested record set. The strength of the guarantee grows with the coverage of the records you ingest. This is not a universal claim, it is a precise, mathematically bounded result within a defined scope. That precision is what makes it regulatorily useful.
MiCA requires CASPs to maintain and demonstrate transaction traceability. 132recon provides verifiable, scoped query results that support documented traceability processes.
The confirmed negative as a first-class result provides a defensible, loggable output for AML compliance processes, not an estimate, a guarantee.
132recon runs on your server. Sensitive financial data never leaves your environment, satisfying both compliance and commercial requirements under EU data regulation.
Regulators increasingly require auditability of compliance systems. Code is disclosed on agreement, full transparency for compliance and legal teams.
132recon deploys to your infrastructure, configures to your record sets, and integrates into your existing workflow. Every engagement starts with a conversation.
We discuss your workflow, your record sets, and the integration point. Pre-transaction, post-transaction, or audit, determined by your use case.
On agreement, the code is disclosed. Your technical and legal teams have full visibility into what is being deployed. No black boxes.
132recon runs on your server. Your data stays in your environment. We support the deployment and integration process throughout.
The system runs against the record sets you have access to. The scope of the guarantee is defined by those records and clearly documented.
Runs on your own infrastructure. No cloud dependency, no data transfer to third parties. Full control over your environment.
Not open source, not a black box. Full auditability for compliance and technical teams who need to understand what is running.
Integrates into your existing compliance, fraud, or operations workflow. 132recon returns a result, what your system does with it is up to you.
Access can be managed programmatically, time-limited, query-limited, or scoped to specific use cases.
Every confirmed negative is scoped to the ingested record set. The system is precise about what it can and cannot guarantee, which is what makes it useful in regulated contexts.
The search-at-scale demo runs a query against an ingested record set and returns the typed result with its scope.
Every query and its typed result, Hit or Confirmed Negative, with the scope of the guarantee, sealed as an entry. The existing compliance audit trail, as an add-on.
Privacy, compliance and safety don't ask what's relevant. They ask whether you found everything. Ranked and nearest-neighbour search, the kind under every AI assistant, returns the closest matches and no account of what it skipped. That cannot answer a regulator, a court or an inspector. A closed-world search over a surveyed estate can.
Nobody will give an external platform delete rights across the CRM, HR, billing and backups, and they shouldn't. Discovery provides the map; execution returns to you. Each system's erasure is a rung, run by the team that owns that system, under their own permissions, with a record that proves each step ran.
Data GPS across mail, shares, archives, backups and exports. Every form the person takes. The scope statement travels with the result.
One rung per system. The CRM team runs the CRM rung; HR runs theirs. Same manifest, different hands. No access granted outside.
The request, the search, each erasure, the sign-off, sealed, replayable, verifiable by a regulator who was never given the data.
The request from the Data GPS walkthrough, one week on. 312 occurrences across the CRM, the HR system, two file shares, a mail archive and a legacy export. Six systems, four owning teams, one deadline, and a regulator who may ask to see it done.
See the rung itself in the Rung walkthrough →
The request, the search, the check, each erasure and the sign-off as one sealed chain, what was decided, by whom, on what evidence. Optional, priced separately, always available.
Not the offering, the offering is the primitives. These are three examples of what a specification looked like once it was written for a client: what it discovered, what it found at risk, what it gave back. Yours will differ.
A subject access or erasure request is a closed-world question. The AI Act and NIS2 add a second one: what did the systems do with it, and can you produce the record.
First step: one request, one estate, one afternoon, a complete answer next to the one you gave last time.
Every regulated company has a list: the regulator's requests, the audit standard, the litigation hold, the contract obligations. Each one is a demand to produce records completely, on a deadline, from an estate nobody has mapped. the regime, sector rules, audit standard, reporting obligations, is written into the specification per client
First step: one matter, one hold or one regulatory request, run against the whole estate, one afternoon, inside your perimeter.
Daily field records, inspection checks, permits to work, toolbox talks, incident reports, training certificates, environmental monitoring. Filed by site, by contractor, by year, in every format.
First step: one site or one contractor's records, one afternoon, and the gaps show themselves.
Every model call and agent run leaves a record, prompts, responses, what was retrieved, what it cost. It is the complete account of what the AI did, and nobody has read it. Same tool, second pile: the logs are data too, read where they sit, nothing copied.
What makes this different is what runs: the model as a Go binary that spins up, does the job and tears down, with no framework, no protocol surface and your keys never leaving your environment, and Rung, which is what those binaries run inside. Start there, then the three things it lets you see.
Two agent binaries and a router, stateless, no MCP, no LangChain, your keys. Seven bricks. What runs inside a rung, and why a wrapper can't.
You integrated AI. Now the codebase is dark. What's in it, what the model re-reads, and the rule that wasn't written anywhere it could see.
The AI logs. What was read, how often, by whom, for what. What was produced. What repeats. Cost per outcome, not a token total.
AI Act record-keeping, NIS2, and a record you can show: what the model saw and produced, searchable and sealed.
Every AI-assisted change adds code, artifacts and generated files nobody mapped. The model has no memory of the repo, so it re-reads it on every call, and each change is harder than the last because nobody, human or model, can see the whole thing.
¹ Published analysis of agentic coding sessions: input tokens, mostly re-sent context, often exceed 99% of volume; the largest driver is context re-reading because the model has no memory between turns. Augment Code, 2026.
Recon 0 and 1 on code produce the map a model should be handed instead of the repository.
Every call, the assistant reads to find out where it is: pulls in files, follows imports, guesses at structure, re-discovers the same routes it discovered an hour ago for someone else. The reading is the bill; the fix is the remainder.
Given the map, the model reads the three files that matter instead of the three hundred that might. Given the honesty record, it knows what it wasn't shown. The cost of the call drops to the cost of the work.
The rule that lived in fifty heads becomes a rung: a check the generated change has to pass before it moves on. The correction happens once, in the structure, instead of a hundred times by hand.
{
"repo": "payments-core",
"files": 2311,
"entry_points": [ "cmd/api/main.go", "cmd/worker/main.go" ],
"dependency_roots":[ "internal/ledger", "internal/auth" ],
"unused_exports": 57,
"orphaned_files": 23,
"missing_tests": [ "internal/fx/convert.go", "internal/auth/refresh.go" ],
"rules_in_heads": [ "amounts are minor units; never float" ] // ← written down for the first time
}An older deployment has a rule: amounts are integers in minor units, never floats. It isn't written anywhere a model can see. So every morning the assistant generates code with floats, every developer catches it, every developer fixes it, and the fix never propagates because the model has no memory of yesterday. Fifty areas, a hundred people, one correction, daily. Nobody sees it as one thing.
The rule, the gate, every pass and every stop, sealed, so the change in the logs is a fact you can show, not an estimate. Optional, priced separately, always available.
Every model call and agent run writes JSON somewhere: prompts, responses, token counts, tool traces, which documents were pulled into the window. Huge, unstructured, and the complete record of what the AI did and what it cost. Recon treats it like a file share.
Recon 0 shows how much log there is and where. Recon 1 sorts it: prompt logs, tool traces, embedding runs, billing exports. Recon 2 pulls the metadata that answers the questions.
Which documents went into the window, how often, by whom, for what. Which content was embedded again and again because nobody knew it was already there.
Every output, searchable closed-world. What the model said about this customer across every call last quarter. Every decision traceable to its step.
The re-reading. The retry after a miss. The same fix made daily in fifty places. The step that keeps failing. Cost attached to an outcome, not to a token total.
{
"surface": "assistant-logs/2026-Q2",
"calls": 418902,
"documents_read": 9126,
"read_gt_5x": 1311, // the same document, six or more calls
"top_reread": [ "policies/retention-v7.pdf", "schemas/orders.sql" ],
"outputs": 418902, // every one searchable
"repeat_outputs": 0.31, // share matching an earlier output
"retries": { "after_miss": 22417 },
"by_team": { "support": 0.44, "finance": 0.21, "eng": 0.35 }
}A support team's assistant answers policy questions. The bill has tripled in a year and the answers haven't improved. The AI lead can see tokens per day and nothing else. Nobody has opened the logs.
Reads, outputs and repeats sealed per period, so the change from one quarter to the next is a record, not a dashboard. Optional, priced separately, always available.
The AI Act asks what the system saw and produced and whether you can produce the record. NIS2 asks for the audit trail. Telemetry can't answer either, because it watches the pipe and the outputs are text nobody built a way to search exactly. Read the outputs as an estate, search them closed-world, seal them, and the answer is a root, not a reassurance.
A regulator asks what an insurer's claims assistant said about one policyholder over a quarter, and on what basis. The vendor dashboard shows call counts. The answer has to be every output, complete, with what the model was shown each time, and it has to hold up if challenged.
Every step of a model's reasoning and every human decision captured alongside the data that drove it, sealed as it happens, for Article 12 and for the audit. Optional, priced separately, always available.
Each agent is a Go binary. It spins up, does the job, and tears down. No state carried between runs. No MCP. No LangChain. No additional security surface. Your API keys, your model, your infrastructure. The agent is the binary. The binary is the deployment. Nothing else runs.
Typical agent frameworks bring a runtime, a dependency chain and a protocol surface into your perimeter, and pass your keys through all of it. A binary brings nothing in.
The agent is the binary. The binary is the deployment. Nothing else runs.
Two binaries put a model to work; a third routes stateless data between steps. All three are deployed stateless: nothing is kept inside the binary between calls.
Enterprises that won't allow a Python runtime with a hundred pip dependencies on a production box, and there are many, can deploy a single binary. The industrial side can put it next to the PLC.
An interpreter and its packages, each one a version to track and a CVE to watch. On every host the agent runs on.
MCP servers, tool endpoints, connectors: every one a listener, every one a path in. The surface grows with each tool added.
Compiled Go. No runtime, no interpreter, no package manager on the box. One thing to sign, one thing to patch, one thing to carry into an air-gapped estate.
Nothing is held open. It runs, writes a state file, exits. There is no protocol for a tool to reach in through, so there is nothing to harden.
Standard RAG retrieves chunks by similarity from a vector store. For internal data where you know what you have after Recon, you do not need similarity. You need completeness. Same LLM on the output side. Completely different retrieval on the input side.
For internal data you already hold, you do not need similarity search. You need to search it completely and prove you did.
SAME LLM · DIFFERENT RETRIEVAL · COMPLETE NOT APPROXIMATE · see how a question becomes a search tree →
For AI, the fit is the data path and the decision, not the model's intelligence. A binary that holds nothing and listens on nothing is the only kind of thing that can run as a rung, because a rung is a bounded, stateless step that executes once, reads its inputs, produces its outputs, and stops. A wrapper with persistent state and an open protocol surface cannot be bounded; it can only be told to behave.
Where the binaries sit in a pipeline. The model runs in its own lane; the gate contains no model and reads no model output.
Data pipelines, ETL processes, batch processing systems, algorithmic trading, and scientific computation all need the same properties: bounded steps, auditable inputs and outputs, deterministic execution, resumability after failure. Today these properties are reimplemented ad hoc in every system, with varying degrees of correctness, and the guarantees live in convention rather than structure. A pipeline built from rungs has these properties by construction. Each step is isolated. Each step's inputs and outputs are recorded. The manifest defines the workflow declaratively. Resumption after failure is a property of the execution model, not a feature bolted on afterward.
Streaming sketches, anomaly scoring and graph propagation. Each one compiled, each one independent, deployed on its own, chained into a group, or embedded in something you already run. Go 1.22+ · compiled · one, some, or all.
THE METHOD IS GENERAL · THE DEPLOYMENT IS NOT, what a given deployment looks like is set by the data and the question, not by the binary. These seven are the first of the full list →
Each brick reads input, produces output, and exits. No server to stand up, no state carried between runs, nothing held open. The same input gives the same output every time it is run. Stateless means reproducible, the same run, on the same data, twice.
An entity carries three independent descriptions: a sequence over time, a set of attributes, and a position among other entities. A method reading one has no access to the other two. Chained, each stage hands its result forward as input to the next.
FOUR OF THE SEVEN · ONE ARRANGEMENT, and in a pipeline, four rungs with a state file between each.
Every rung a model ran in, with its state files sealed as entries. Chain of thought for Article 12; a failure rate you can show, not estimate. Optional, priced separately, always available.
And gives you back what you need. A search for data, compliance and AI monitoring. Runs where your data already is, messy and unstructured. Self-hosted, nothing leaves the environment.
Given some data somewhere, find what is relevant, account for what was searched, and prove what was done. Four sub-problems, interconnected.
Scope is a budget and priority decision made before anyone types a query.
Data is fragmented across formats, systems, and access levels.
Can we say we looked at everything and confirm what is or isn't there?
A full proof chain: scope defined, sources touched, items evaluated, nothing skipped.
DETERMINISTIC · DYNAMIC · THE GAP BETWEEN THEM
Every search method makes a tradeoff. Speed against completeness, precision against recall, structure against flexibility. No single method covers all data or all questions.
EACH METHOD CUTS CORNERS SOMEWHERE
Before a search runs, someone decided what was worth curating. That decision, a budget and priority call, determines what is searchable and what is dark.
Volume is the point. Searchability depends on what sits on top.
Optimised for known queries. Questions outside the model have no field to land on.
The most searchable, the most expensive to maintain. A fraction of total data.
Unindexed, uncatalogued, sitting in file shares, email, legacy systems. Invisible to every search.
A search result comes with an invisible asterisk: here is what we found within the portion of data we chose to invest in.
Compliance says we need a report. The data sources are known and mapped. The extraction is defined. The output is a dashboard. The whole thing is a pipeline. It works, it is trusted, it runs on schedule.
Completeness is assumed, not proven. The process is the proof.
The goal is a question someone typed. The search space is not predefined. The data might not be structured. The output is generated, not templated. At the end there is no log that says what was considered and why.
Completeness is unknown. Provability does not exist.
Deterministic sidesteps the hard problems by locking everything down. Dynamic tries to operate in the open world and fails on all four. Nobody has a clean architecture that solves all four across both branches.
ANN is approximate by design. Indexes skip. Embeddings compress. Even SQL only answers within one database. No method at scale truly searches everything.
Logging the query and results is easy. Logging what was skipped is nearly impossible. An HNSW graph prunes paths it never explores. Those are invisible misses.
50–80% of enterprise data is not searchable. Not because it is worthless but because nobody invested in making it accessible. Every result ignores it.
What to search is a business decision made long before anyone typed a query. If you scoped wrong, completeness is meaningless. You were looking in the wrong place.
Dark data, not searchable, not curated, not catalogued, sits between 50% and close to 80% depending on the company. This is not a failure. It is a budget decision. But it means every search result carries a caveat.
Feeds the dashboards, has APIs. Where deterministic pipelines operate.
Email attachments, local drives, legacy systems, PDFs, Slack threads. Investment needed to reach it.
Old systems, departed employees, undocumented databases, shadow IT.
NOT A FAILURE · A BUDGET DECISION
Four components, each solving one of the four sub-problems. Seek Map defines what to search. Data Router finds where it lives. Closed World Search guarantees coverage. Mini Ledger proves what was done.
Takes the described data and the goal. Writes a specification of what will be searched, across which surfaces, to what depth. Stated before it runs.
Routes to the right sources regardless of format. CSV, API, database, file share, email. The search reaches what it needs to reach.
Searches the complete surface within the defined scope. A negative is a result. A count is a count, not an estimate.
Seals what was asked and what came back into an immutable, independently verifiable record. Merkle proofs, chain of custody.
SCOPE · ROUTE · SEARCH · PROVE
The search will put any question to everything held. It does not decide what the question is. Seek Map does, it takes the described data and the goal, and defines what will be searched, before anything runs. Not where to look, Recon already mapped that. Not how to get there, the route mapper handles that. The seek map defines what: the terms, variations, and relationships that constitute the search.
A search you cannot state in advance is a search you cannot repeat.
The search decides its own scope at runtime. No two runs are the same. No way to repeat or audit the decision.
The scope is written down before the search runs. Repeatable, reviewable, auditable. The specification is the deployment.
TERMS · VARIATIONS · RELATIONSHIPS · STATED BEFORE IT RUNS, the prose is the trigger; the specification is the search. Dynamic and deterministic modes →
The route mapper uses what Recon discovered about data shape and format to find the path to each piece of searchable data. Different data shapes need different extraction. The route mapper reads the Recon output and picks the right path. A scanned PDF goes through OCR. A text PDF goes through direct extraction. The search sees the same content either way.
DATA SHAPE DETERMINES THE ROUTE · SEARCH SEES THE SAME CONTENT
Within the defined scope, every item is evaluated. A negative is a finding, not a failed lookup. A count is a count, not an estimate. The search completes and can say what was and was not there.
The question is put to every item within scope. Not a sample. Not top-K. Not an approximation.
Nothing found means nothing was there. Within the scope that was defined, the answer is definitive.
Each query and its result is captured, accumulated into a block, and sealed with a Merkle root.
Which searches were run, when, and what came back. Verifiable by a third party without handing over the data.
The search gives the answer. Mini Ledger makes the answer something you can produce again later.
Point it at a set of data, define what you want to search, search a portion or the complete record. Ask a question and receive accurate search results.
Finds the data you need, a complete record search if that is what is required, closed world.
This is where we define the parameters, what is to be searched. In curated data simple; in messy data it needs to be complete.
A complete record that is accurate, and complete.
The condition of the data decides how far a search has to go. Where it is curated, a defined slice answers the question. Where it is messy, a slice answers nothing and that is where the scope has to be set wider.
Fields are known, values are consistent, and the place to look was decided when the system was built.
Mail, exports, attachments and years of accumulation. No shared field, and nothing arranged for the question being asked.
Scope is chosen per search, so the same tool serves a tidy system and an unmanaged estate.
THE DATA STAYS AS IT IS · THE SCOPE MOVES
Both start with locating the records themselves, wherever they sit. The search finds them and reports what they are. What follows is decided under a schedule you hold.
Across mail, drives, exports and attachments, reached as they are. A routine check may take a portion; an erasure request takes the complete record.
What the item is, where it sits, and when it was created, returned with the content itself.
Your criteria, your retention schedule, your decision. The search locates and reports; the rules stay yours.
THE SEARCH FINDS THE DATA · THE RULES STAY YOURS, execution as rungs: the erasure walkthrough →
Alongside inventory and classification, high-risk systems carry a record-keeping obligation: events logged automatically across the system's lifetime, retained for a minimum of six months, with full application from 2 August 2026.
Which input, dataset, prompt, tool call or artefact was used, and which were considered and set aside.
The result returned, against which alternatives, with the basis recorded at the time.
When it ran, which version and configuration were active, what went out and to whom.
EU AI ACT · ART. 12 RECORD-KEEPING · ART. 19 RETENTION
Recon describes the data. Seek map takes that description and your goal, and writes what the search will do. That written specification is the deployment, and it is set per customer.
Surfaces, scope, criteria. Which surfaces are searched, how far the search goes, what counts as a match, and what comes back, written down before it runs, so it can be read, reviewed and run again.
One spec per purpose. A pull built for a defined job. Set per customer, and changed later by editing the specification rather than the binaries.
The same request runs the same way next quarter and next year. Per customer · per question.
Context is fixed, so whatever is placed in front of a model is the whole of what it has to work from. Selecting that is a scope decision, the same one, pointed at a different consumer. Search first, then the model.
THE WINDOW IS FIXED · THE SCOPE IS CHOSEN · replaces RAG for internal data →
Each item comes back with where it sits and when it was created, because that is what was searched. For a record that has to hold up later, a statement is worth what its source is worth.
Each item arrives with where it was found, so the answer and the evidence for it are the same object.
Text is held as text. What was said, what was drafted and what was floated come back alike.
An entry that can be traced to the item it came from, and checked by someone who was not there.
The file gets a source, not a sentence.
The same search feeds two kinds of output. A deterministic report structure for compliance and audit. Or an LLM with a template for dynamic questions. Both carry provenance because both start from the same closed-world search.
Search results feed directly into a defined report structure. Dashboard, Power BI, compliance filing. Same search, same format, same output every time.
Search results placed in front of a model as context. The model works from what the search returned, not from what it recalls. The window is filled with verified data, not retrieved approximations.
Both paths start from the same closed-world search. Both carry the same proof.
Four algorithms monitoring the same data. Individually data could look normal but as a stack gives you better insight. Better decision making. DTW on week-by-week activity · iForest and OCSVM on account details · GraphProp on shared connections.
FOUR ALGORITHMS · ONE SET OF DATA · ONE SET OF EXAMPLES · YOUR DATA DECISIONS · the seven bricks → · the full list →
The binaries stay the same. What changes is where they sit and what they have been specified to do. Runs on your infrastructure. Nothing leaves the environment.
Deployed into an environment and run directly, on a schedule or on demand, by the people who need the answer.
Built in as a capability rather than a product of its own. Your interface, your workflow, your name on it.
Specification, pulls and outputs shaped to a defined job, and changed later by editing the specification.
Recon surveys the data. Seek Map defines what to search for. Route Mapper finds the path. Search executes. Output goes to a report or an LLM. The log and output seal into Mini Ledger.
Each query and its result captured, accumulated into a block, sealed with a Merkle root. Any party can verify any record without being given access to the underlying data. Optional, priced separately, always available.
A rung is one bounded, stateless step: it reads its inputs, produces its outputs, and stops. Same inputs, byte-identical outputs. A check is not a habit; it's a step the pipeline can't get past. Rung brings the execution model of a PLC ladder to data workflows, and to the models running inside them.
Read them as what they do, or as the artifacts they are.
pipeline: erasure-request-4471
rungs:
- id: find from: search out: occurrences.json
- id: validate from: policy-check in: occurrences.json
gate: true # pipeline halts here if not passed
- id: erase-crm from: crm-erase in: occurrences.json
- id: erase-hris from: hris-erase in: occurrences.json
- id: record from: seal in: [erase-crm, erase-hris]{
"rung": "validate",
"input": "occurrences.json",
"checked": 312,
"passed": true,
"value": { "exact": "312/312", "display": "100%" },
"hash": "9f1c…a37e",
"signed": true
}A persistent agent with broad access has no controls, only preferences. Inside a rung the model runs once, on one task, with no memory across invocations and no path around the check downstream. It can be as clever as it likes; it has nothing to bypass it with.
For code to execute as a rung it has to satisfy every layer at once, encryption, integrity, base validation, and the manifest topology, and injected code satisfies none of them without the key. A conventional ladder offers no such barrier; implanting logic is simply editing it. What the layers guard is code entering through the pipeline; an air-gapped deployment closes the path outside it.
The compiled program is encrypted for distribution. Not readable, not editable, between steps.
Signed; the runtime refuses a program that has changed by a byte.
Each rung's values are checked against the base it declares. Out-of-base input doesn't run.
Only steps named in the manifest, in the order it names, with the inputs it names. There is no other way in.
The safety is structural, not content, the same contract ladder logic has always had. You can build a rung that does the wrong thing, exactly as you can program a PLC to do the wrong thing. What the structure guarantees is that whatever the step does, it does it inside a boundary you can inspect, bound, replay and reason about. The code and pipeline protection is Rung's; correct deployment is yours.
Rung is a working programming language with a runtime implemented in Go. It implements exact multi-base arithmetic as a built, tested system, not a proposal. This section says what it does and why, not how it is implemented.
Every modern computing system does arithmetic in base 2. This works perfectly for values that are exact in binary and fails quietly for everything else. One divided by three becomes 0.33333… with a rounding error in the last bit. Multiply that by three and you do not get one. Do it a thousand times in a loop, accumulating a running total, computing a weighted average, normalizing a score, and the error compounds. Not catastrophically. Not on any single operation. But steadily, invisibly.
The standard response is tolerance checks, rounding functions, correction factors, and the occasional unexplained +1 that nobody can remove because doing so breaks something downstream. These are not solutions. They are concessions to a representation that rounds where the math does not require it. The root cause is always the same: the number base does not fit the operation.
Rung routes each operation to the number base where it is exact. Division by three runs in base 12, where one-third is exactly 0.4, a terminating fraction with no rounding, no approximation, no error term. Bit manipulation runs in base 2. Three-state decisions run in base 3. Decimal values run in base 10, where tenths and fifths are exact.
Values cross between bases through a canonical form: an exact rational number, numerator and denominator, both arbitrary precision. The conversion is lossless. Rounding stops being something that happens on every operation and becomes a deliberate act, at output, or where a transcendental function genuinely has no exact rational form. Everywhere else the arithmetic is exact and verifiably so.
Bitwise AND, OR, XOR, NOT, shifts and masks on the native binary representation. Flags, status words, hash indices, tree structures belong here.
A comparison returns a trit, less, equal, greater, directly usable in a three-way branch. Three-state machines encode naturally.
Factors into both 2 and 3: the natural intermediate for values consumed by both binary and ternary operations. Exact senary arithmetic today; bridging operations planned.
Tenths and fifths are exact, which suits currency, measurement, and any data that arrives in decimal form.
One-third, one-quarter, one-sixth and one-twelfth all terminate. Any division whose denominator divides 12 is exact, most real-world division in measurement, proportion, finance and engineering.
The sandbox demo for this page is scheduled in the build phase. The slot is here so the page shape is final.
Four head-to-head comparisons run the same computation in Rung's exact rational arithmetic and in standard IEEE 754 binary floating point.
A rung declares its base. The computation inside runs in that base, exact for every value whose denominator's factors divide it. The result leaves as a state file.
The state file carries the exact rational value, its base, its display form, and a hash. The next rung reads the exact value, not an approximation of it, whatever base it runs in.
Rounding, if any, happens once, deliberately, where a human or a display needs a decimal. Never silently in the middle of a pipeline.
{
"rung": "balance",
"base": 12,
"value": { "exact": "1/3", "base": 12, "display": "0.4" },
"hash": "51ae…c0d2",
"signed": true
}An erasure request: one person, found in the CRM, the HR system and two archives. Each system is owned by a different team, and none of them will give an outside platform delete rights. The erasure has to run inside the perimeter, by the people who own each system, and afterwards someone has to be able to prove it ran.
Every rung seals itself. The Merkle root covers the pipeline. Chain of search, chain of decision, chain of thought stop being descriptions and become what a pipeline produces by running.
Stateless Go binaries. Each one reads input, computes, writes output, and exits. No server to stand up, no state carried between runs, nothing held open. The same input gives the same output every time it is run. Each one independent, deployed on its own, chained into a workflow, or embedded in something you already run. One, some, or all.
What a given deployment looks like is set by the data and the question, not by the binary. Every method below is deployable today as a Go binary. Most are modernised variants of the published method, streaming, mergeable, drift-aware, or with operations the original lacked. Each will have its own page.
Several run in sequence, the output of one becoming the input of the next, a state file between each, hashed, and the record sealed. An entity carries three independent descriptions: a sequence over time, a set of attributes, and a position among other entities. A method reading one has no access to the other two. Chained, each stage hands its result forward.
feed | filter | score | routePick the brick the question needs. Run it where the data sits, a stream, a log, a table, an event feed, and read the output. When one isn't enough, chain them into a workflow, each step on the record. No platform, no vendor lock, nothing that phones home.
Request a free pilot →The primitives are a foundation to build on, not a platform to depend on, no runtime to adopt, nothing that phones home, nothing of ours in your product's path. Deploy them under your name, for your clients, on their infrastructure or yours. The kit: the binaries under keys, the deployment guides, the price sheet, the paper. Referral, then reseller, then embedded.
Join our network →A workflow of bricks with a state file between each becomes a chain of entries. What ran, in what order, on what input, with what result, verifiable without the data. Optional, priced separately, always available.
Mini Ledger produces what a blockchain produces, immutable records, Merkle proofs, chain of custody, from a single binary and one JSON file, on your server. No coin, no node, no gas. Any party can verify any record without being given the data. It's the add-on to every Data and AI solution, and a product on its own.
Every record follows the same path, submitted, bundled, sealed, linked. The Merkle root is the proof. The chain link is the continuity.
Any data, a transaction, a decision, a search result, a rung's state file. Your system sends it to Mini Ledger.
Timestamped, hashed, added to the pending block. Accumulates until the trigger fires.
By time or by count. Merkle root computed, block linked to the previous one via the genesis chain.
Any party verifies any record from the root, without the data. Optionally anchored to a public chain.
{
"chain": "erasure-4471",
"block": 118,
"entry": { "ts": "2026-09-12T14:03:22Z",
"type": "rung.state",
"hash": "9f1c…a37e", // the rung's state-file hash
"payload": "encrypted" }, // AES-256 at rest
"merkle_root":"e4b0…77d1",
"prev_block": "c2a9…5f10",
"anchor": { "chain": "xrpl", "mode": "public", "tx": "A93F…" }
}The Mini Ledger demo runs the primitive in the browser: submit entries, watch the block trigger fire, compute the root, verify without the data.
The first four are about where the ledger sits. The fifth is about who else can verify it. "No gas" is true of the ledger; an anchor is a small, scheduled cost you choose, on a chain you choose.
Four cases, each a walkthrough in the build. Told as the situation, the steps, and the two outcomes, sealed, or rejected.
Two parties agree what the record was at a point in time. The anchored root is the thing neither can later dispute, without either seeing the other's data.
The private ledger holds the transactions; the public anchor proves the batch existed and hasn't changed. Pairs with search at scale for Hit / Confirmed Negative on the same records.
Obligations, amendments and sign-offs sealed as they happen, with a timestamp that survives either party's systems. Chain of decision for the approvals.
Mini Ledger as the system of record for what lives on a chain: tokens, credentials, instruments, assets, loyalty points. The chain carries the anchor or the asset; the ledger carries the full, sealed record inside your perimeter. Contained by architecture, not by policy.
Every Data and AI page ends with "Add Mini Ledger." This is what the seal gives each of them.
The spec, the scope statement, the occurrences, the hash, or, at scale, Hit / Confirmed Negative with the scope of the guarantee. Proves which checks ran, when, and what they returned.
Human decisions captured alongside the data that drove them. The request, the check, each erasure, the sign-off. Approver and timestamp immutable.
Every rung a model ran in, with its input and output as state, sealed as it happened. Record-keeping for Article 12 that the system under audit didn't write about itself.
Every rung seals itself. The Merkle root covers the pipeline. That's why the add-on is one line on every page: it's already the shape of the work.
This started as Aagentix, a multi-agent system. As we ran into multiple issues and solved them, 132recon evolved from that effort: Mini Ledger, the primitives for agents, stateful and stateless agent deployments as a stateless spun-up architecture. Then understanding how to search AI records, chain-of-thought tracking and output tracking, had to be solved, and that became the foundations for 132recon. The work ran through XRPL Commons' Aquarium AI cohort 6 (April–July 2025) and the Aquarium alumni cohort (July–September 2026). Mini Ledger's anchor was first built and proven in the XRPL ecosystem; the anchor itself is chain-agnostic.
132recon is part of 132 ENG Inc., a Canadian company. We deploy in the EU and the US as required. The data never goes anywhere; only the binary crosses a border.
Canadian by default, which reads as neither American nor Chinese in a sovereignty conversation and carries an EU adequacy decision. A local entity in the EU or the US where a market requires one. The product doesn't change; the letterhead does.
Solution provider, not a platform. The binaries run on your infrastructure or your partner's; nothing is hosted by us and nothing of yours is held by us. Internals are disclosed on agreement, to your technical and legal teams.
This started as Aagentix, a multi-agent system. Solving the problems that surfaced. Mini Ledger, the primitives for agents, stateless spun-up deployments, and then how to search AI records, chain of thought and outputs, became the foundations of 132recon. Supported through XRPL Commons' Aquarium programme in Paris: AI cohort 6 (2025) and the alumni cohort (2026). Further certifications will be listed here as they are granted.
All conversations are confidential · No commitment required · We respond within one business day
Four entrances for four readers. Every document has the same shape, purpose, contract, invariants, artifacts, non-goals, change log, so a reader who has understood one can read all of them, and the non-goals section of each is where the internals are explicitly excluded. What crosses the boundary and what you can rely on. Internals are disclosed on agreement.
ORDER · Deploy it and Trust it first, what a partner's first engagement runs on and what a DPO reads before anyone else is allowed to. Use it second, driven by the first pilot. Build on it last, when there's a startup asking for it. Every page carries its version and date. French per document, as partners need it.