The numbers a small business ran on, and the owner's reasoning behind them.
Spakari works with owners of privately held businesses. We take their tax returns, books, payroll and sales records, turn them into structured data, and interview the owner about the decisions those records show. A lab receives the data, the owner's answers, and the links between them. The names of people and private companies, and every identifying number, are removed before anything leaves. Public agencies and companies keep their names. Every record says which document it came from and under what consent.
What our data shows is not found in a document
The owner's reasoning, tied to the numbers
A ledger shows that a contractor stopped paying a subcontractor in 2023 and that payroll gained a salaried technician the same year. It does not say why. Spakari's interviewer finds that change in the records and asks the owner about it. The answer is recorded with a link back to the payroll rows and to the finding that prompted the question. The answer carries what the owner considered instead, what they expected, and what came of it. Answers are labeled retrospective, because the interview happens after the fact. The one exception is a plan, memo or email the owner wrote at the time, when the owner has one. That ships labeled contemporaneous.
Provenance on every record
Every record carries the same five provenance fields. They are the source document, the collection date, the consent ID, the agreement version and the redaction version. Every narrative also carries evidence_refs, a chain that runs from the owner's sentence to the finding, from the finding to the rows it was computed from, and from those rows to the documents they came from. You can follow any sentence to its numbers and any number to the sentence that explains it. A question with no data behind it says so in the same field.
Consent you can audit
The owner signs a one-way NDA before uploading anything. Before the contract is signed, the owner's identity, business and tax ID are verified through Stripe, and a public-company screen is run against the SEC's list. The contract then lists every document by year and source, and the owner signs a standards acknowledgment with it. Each record's consent ID points to that agreement and its version, so a record can be traced to the exact terms the owner accepted. Inside Spakari, names live in a vault that is opened only through logged access. When a package is complete, the vault's names are deleted and only one-way fingerprints remain.
The same person is the same code, every year
Every person, place or private company gets one code the first time it appears and keeps it in every record type and every year, from the 2019 payroll row to the 2023 ledger line to the owner's answer in 2026. The code ships with a plain description such as "the foreman hired in 2021." That is what lets a model follow a business over time without ever holding a name.
An interviewer that asks like an owner
The interviewer is built on one idea. Ask the questions a new owner would ask a veteran. How do you decide when to hire? What do you aim for on labor? Why did you stop doing that? It reads the records first, so it asks about what happened in this business rather than in businesses like it. Every question passes a gate before the owner sees it. The gate log keeps what was asked, what was rewritten and what was declined, and it is available on request.
Built for evaluation as much as training
Everything carries a date, so a time cut is a query. A model can be given a business's records and reasoning through one year and asked about the next, and the answer can be scored against what happened. Spakari also keeps synthetic businesses with complete answer keys. They are how the pipeline measures itself, and they are what a lab can test against without touching a real owner's records.
Measured against known answers
The first real package was the founder's own business. It holds 42,798 records across twelve record types, and every gate passed.
Before any business other than the founder's goes through Spakari, every stage runs on synthetic businesses generated with a complete answer key. On the synthetic contractor, eight years of records, two independent readers each read all 7,955 ledger postings, and their readings matched the key and each other line by line. An earlier version of one reader had read 5,837. That number is in the report too, because the measurement is what found the fault. At export, every identifier planted in the key was caught. Three one-word names survived the first export. The check that catches them is now a gate, and the second export was clean. The tax-return reader is scored against the IRS's own published test returns. The measurement report for any package is available on request.
The second synthetic business, a service business with five years of records across three accounting and payroll programs the pipeline had never seen, went end to end in October 2026. All twenty planted identifiers were removed. The measurement report is available on request.
Every document gets a fixed reading. When a file's layout is one the pipeline has not seen, it also gets a second reading from a model working in an isolated sandbox with no network access, a stripped copy of the file, and a log of every line of code it ran. Code checks both readings against the file's own totals, and a third reading settles any disagreement.
What a package contains
A package is one folder per business, with one JSONL file per record type and a manifest. Every record carries the same five provenance fields. The manifest carries record counts, the years covered, coverage in three figures (declared, read and exported), the standard version, and the result of every gate. If your schema differs from ours, the mapping is on our side.
| File | Contents |
|---|---|
manifest.json | Counts per record type, years covered, coverage as declared, read and exported, the standard version, and the participant list |
annual_layer.jsonl | Normalized annual financial groups, by year, with source and grain |
payroll_year.jsonl / payroll_period.jsonl | Roles and categories by year and by period, with hours, pay components and tenure. Named by code and role, never by name. |
revenue_group_year.jsonl | Sales groups confirmed by the owner, by year |
entities.jsonl | Every code with its description and role, the owner's own entities included |
decision_narratives.jsonl | Every question and answer, with shape, participant, retrospective flag, and evidence_refs |
findings.jsonl | What the finder saw and whether the story already covered it |
token_dictionary.schema.json | The schema of the code dictionary. The dictionary itself never ships. |
The redaction standard
Written so that counsel can read it without an engineer in the room. The full standard ships with each package under a version number.
How names and identifiers are found
A pattern pass removes identifying numbers at intake. Two independent model readings then look for names in context. Anything one finds and the other does not goes to the owner, who is the one person who can recognize them. Before export, every record that will ship is read twice more.
Identifying numbers are removed, not coded
Social Security numbers, EINs, and account and loan numbers are removed the moment a file is read and never carried into any record. Only the few people at Spakari who need to see an owner's original files can open them, and we delete the files on a set schedule.
Codes instead of names
A person, place or company gets one code and keeps it in every record type and every year. The description that ships with the code, "the foreman hired in 2021," is what a reader needs. The name never ships. After delivery Spakari no longer holds it either, only a one-way fingerprint that keeps the code stable if the same person appears again.
Other people appear by role
No name or identifier of a third party appears in a package. Employees, customers and vendors appear by role. Government agencies and programs are named as they are, the IRS or the SBA for instance, and a local office keeps its function but loses its town.
The owner confirms the names
After each set of documents is read, the owner confirms who each person and company is, in plain words, before the records that mention them are used. At the end, the owner approves the package. Any check that depends on recognizing a person is done by someone from the business who knows them.
Nothing ships incomplete
The export stops if any declared document was not read, if any record is missing a provenance field, or if a record would be dropped silently. Every code in the records has an entry in the dictionary and every entry has a record. The manifest records the result of each check.
A final scan of every record
Two models read every exported record, looking for anything that reads as a name or an identifying number. Anything either one flags is settled before export. The descriptions that ship with codes are checked by the same rule, so a description never contains a word of the name it replaces.
Why owners take part
Small business owners do not answer vendor programs. Spakari reaches them through the founder's own standing as one of them, after twenty years running businesses in the Cleveland area. The process was built so that nothing in it feels like an audit. Whatever the trade or the sector, every owner is optimizing for profit, and that shared goal is what makes one owner's reasoning comparable to another's.
How we work with labs
Start from your spec
Tell us the record types and fields you want. The package schema and the manifest both carry a standard version, so a change on either side is traceable to a version.
A small pilot, scored
A handful of businesses over an agreed window. Every package is scored on coverage and depth before delivery, and the scores travel with it.
Consent that holds up
The owner agreement carries the supplier warranties a lab expects, and each record carries its consent ID. Before the first delivery, a lawyer reviews the consent chain end to end, at Spakari's expense.
The demo
A synthetic residential contractor with eight years of records, already read by the pipeline. You can replay a completed interview, read the brief the played owner was given, run an interview yourself, open the reviews, and open the package the way a lab receives it. Nothing in the demo is a real business. Ask for a code and we send one after a quick check.