Excel · Power BI · PowerPoint · Word

Read and write every Microsoft file, byte-for-byte.

Our engine, mica, reads any Excel, Power BI, PowerPoint or Word file exactly as it is, and writes it back byte-for-byte so it opens cleanly in real Office. No Office installed. No fidelity loss. No language model guessing in the data path. Deterministic, or it refuses.

Determinism is a claim you can test rather than take on trust, and a hash is how you test it. Same bytes in, same bytes out, same fingerprint every run.

How the hashing works
databa: one deterministic engine that reads and writes Microsoft Office and Power BI files byte-exact, with no Office installed DETERMINISTIC OFFICE ENGINE READ WRITE XLSX XLSB PPTX DOCX PBIX mica READER read · byte-exact attested no Office installed structured data mica WRITER write · byte-exact XLSX XLSB PPTX DOCX PBIX opens in Office

The most important data format in the enterprise is a black box.

Finance, operations and the board run on Excel, Power BI and PowerPoint. Yet every tool that touches those files makes you choose between two bad options.

Libraries lose fidelity

openpyxl and calamine silently drop formulas, mangle precision, and store a stray = as text. What you extract is not what the file says.

COM needs Excel on a server

Automating real Office means a licensed Excel install, a fragile COM bridge, and non-deterministic output. It is unauditable, unscalable, and a security surface.

So teams paper over it with brittle scripts and hope. There is a third option: a deterministic engine that reads and writes the whole Microsoft surface exactly, with nothing installed.

mica · the reader

Read the whole Microsoft surface, exactly.

  • XLSX
  • XLSM
  • XLSB
  • PPTX
  • DOCX
  • PBIX

Every format, byte-exact

xlsx, xlsm, xlsb, pptx, docx and pbix, plus legacy xls, doc and ppt, plus Visio diagrams and Outlook mail as both msg and pst. A native formula decoder resolves structured references and expands shared and array formulas. Nothing dropped, nothing rounded. As if you opened it in Excel, except it is our program.

It declares what the file can answer

mica does not just hand you cells. A report-shape classifier and a completeness gate emit a capability manifest per sheet, saying "this file supports a per-month tie for 2024-01 through 2024-12," so an analyst reads capabilities rather than cell soup.

Deterministic, no Office installed

One dependency-free engine, byte-traceable, the same output every run. No Excel license, no COM, no cloud round trip. The language model is reserved for reasoning about what the numbers mean, never for extracting them.

Smoke-verified on 2.8M cells across a real 109-sheet consolidated workbook.
162 top-level verbs on the shipped binary, counted from mica --help on 2026-09-01.

mica · the writer

Write it back, byte-for-byte.

Files that open in real Office

mica authors Excel formulas in place, including structured table references, plus Power Query M, VBA, whole workbooks, PowerPoint decks and pbix. They open cleanly in real Excel and PowerPoint, and the engine reads back what it wrote to prove it.

It owns the container, byte-for-byte

An xlsx or pptx is a ZIP of XML parts. Off-the-shelf zip libraries throw the exact container bytes away and re-serialize them. mica owns the OPC container itself, so a round trip is byte-identical rather than merely equivalent.

One engine, both directions

The same Microsoft surface, read and written by the same code. Every write resolves or refuses, so nothing downstream ever sees a silently wrong document.

Hashing

Determinism you can check, not a promise you have to take.

A deterministic engine makes a claim that can be tested: run it twice on the same bytes and you get the same bytes back. That is only worth anything if checking it is cheap, and a hash is what makes it cheap. Four things follow from it.

The file is its bytes, not its name

Every file is identified by the sha-256 of its exact bytes, not by its filename, its size or the date on it. Two workbooks that differ by one character in one cell are two different files, and the fingerprint says so before anything is parsed.

A round trip that hashes back

Because mica owns the container rather than re-serializing it, reading a file and writing it back returns the same bytes. Same hash out as in. A library that re-zips the parts produces a document that looks the same and hashes differently, and that difference is the whole argument.

Nothing in the path can drift

No clock, no random seed, no network call and no language model sits in the read or write path. Anything that could make two runs differ is simply not there, which is what turns a hash comparison into a real test rather than a coincidence that usually holds.

You can check what you ran

Release binaries are code-signed, and the engine stamps its own build sha into its version output. The exact build that produced a number can be named, and named the same way by anyone who re-runs it.

$ mica model.xlsb --manifest
fingerprint  9f2c41a7d0b83e6f 5148c22e7a9b0d3f
read  109 sheets · 2,798,493 cells · 0 parse misses
 Trial Balance · per-month tie 2025-01..2025-12 · opening 1/1/2025
 Monthly Summary - BS · 6 entity bands · 12 period columns

$ mica write rolled-forward.xlsx
authored  formulas in place · structured refs · byte-exact container
 opens in Excel · every other cell untouched

$ mica model.xlsb --manifest          # second run, same bytes in
fingerprint  9f2c41a7d0b83e6f 5148c22e7a9b0d3f
 identical

Illustrative transcript. The fingerprint shown is a sample value.

Designed, not yet shipped

Attestation is the receipt determinism earns.

Signing a hash proves who said something. It does not prove the thing is right, and anyone can do it. The design we have specified goes further: one deterministic engine run is one hop, and a hop records the sha-256 of every input, the sha-256 of every output, the engine's build sha and the checks that ran, signed and linked to the hops before it. The chain is a DAG, content-addressed, carried as a small file beside the artifact.

The point is what a verifier can then do with it.

  1. V1 Chain check, milliseconds. Recompute every hop id, verify every signature, verify the chain is intact and covers the artifact. Refutes tampered artifacts, spliced chains and forged hops.
  2. V2 Input check, seconds. Hash the files you actually hold and compare them to what the chain says went in and came out. Refutes swapped inputs.
  3. V3 Re-execution, the one that matters. Take the archived engine binary at that build sha, re-run the hop on those inputs, and byte-compare the result. Passing means the number is not merely signed, it is reproduced. Any byte of difference is a failure, with no tolerance window to hide in.
  4. V4 Spot check. Re-execution on a sample of hops, with the sample seeded from the chain tip so even the choice of what to check is reproducible.

A hop can also attest a failure it disclosed, for instance "61 evaluator exceptions, listed." Attestation is not a claim of perfection. It is a claim of exact reproducibility, and it carries the bad news forward with the good.

This section describes a specified design with patents filed, not a shipped feature. It is not running today, and nothing else on this page depends on it. The engine behaviour described above, byte-exact read and write with no Office installed, is what is built.

Determinism is the whole point.

The engine does all the extracting and writing, byte-traceable and repeatable. The language model is reserved for judgment, never for reading or generating the file. When the engine cannot resolve something exactly, it refuses instead of guessing.

  • Byte-exact
  • Lossless
  • No Office installed
  • No LLM in the data path
  • Deterministic
  • Resolve or refuse
  • Auditable

In action

What the engine is used for.

  1. Roll a whole workbook a month

    Advance an entire model one period, deterministically, resolve or refuse, with no hand-editing of 40 tabs.

  2. Excel ranges to a live deck

    Tag Excel cells by relative address and bind them into a PowerPoint deck that refreshes when the numbers change.

  3. Power BI lineage

    Trace source, M query, model table, DAX measure and report visual, and separate what is defined from what is actually used.

  4. Deterministic GL processing

    Scan a trial balance or GL for bad debt and write-offs, roll up accounts, and reconcile sets across files with materiality.

What we hand you that stands alone, a model or a report in native Excel or PowerPoint, keeps working on your machines whether or not we are here. Where a deliverable calls our engine, that call runs on our side, because the engine is ours and it stays with us. Your data goes there to be worked on, and nothing readable stays behind.

Put the engine on your Microsoft stack.

Bring us a workbook, a Power BI model or a deck you cannot trust. We prove the value on a small scope first, deterministic and byte-exact, and you keep the result.

Talk to us