# Rohit Patel Wants the AI Document to Show Its Work

> The former Meta AI director is building Ndoc around a visible path from data and code to narrative and presentation. Its early alpha leaves a harder question: can a buyer verify the path and carry it elsewhere?

- Published: 2026-10-28
- Author: Gene Dai
- Canonical: [https://digidai.github.io/2026/10/28/rohit-patel-ndoc-inspectable-ai-document/](https://digidai.github.io/2026/10/28/rohit-patel-ndoc-inspectable-ai-document/)
- Topics: Rohit Patel, Ndoc, AI Documents, AI Workflows, Provenance, Deep Investigation

---

![An editorial illustration of a document connected by visible lines to data, code, and a presentation, beneath the words Show the Work.](/images/articles/rohit-patel-ndoc-inspectable-ai-document/cover-v1.jpg)

_AI-generated editorial illustration._

On October 27, Rohit Patel gave a small company's answer to a large software question. In an
[interview with TechCrunch](https://techcrunch.com/2026/10/27/meta-ai-director-rohit-patel-leaves-to-take-on-microsoft-office-and-google-workspace/),
the former Meta AI director described Ndoc, a three-person, unfunded startup meant to join the spreadsheet, written
explanation, and presentation in one working document. The product was in an enterprise pilot and a limited alpha,
according to the report. A beta was planned for the following weeks, with a broader launch targeted for 2027. Those are
launch stages and founder plans, not evidence that an enterprise has replaced its office suite.

Patel's pitch has a practical center. If an AI assistant builds a financial analysis, a manager should be able to move
from the slide showing a result to the text explaining it and then to the dataset and Python script that produced it.
The manager should be able to ask why a formula was used. A reviewer should be able to carry the work outside the
vendor's application. Patel says Ndoc can connect those steps and export a self-contained file. A buyer still needs to
see what survives that trip.

The timing matters. Microsoft has
[added Python execution in Excel through Copilot](https://learn.microsoft.com/en-us/microsoft-365/copilot/release-notes),
Google has
[announced interactive Sheets canvas apps](https://workspace.google.com/blog/product-announcements/turn-your-data-into-action-6-mini-apps-you-can-create-with-sheets-canvas),
and [OpenAI's Space documentation](https://help.openai.com/en/articles/20001549-getting-started-with-space-in-chatgpt)
describes collaborative pages with slides rolling out. Patel is not arriving in an empty category. His more interesting
wager is that a single inspectable file, built for AI to read and write, could change the unit of work itself. The
difference between an appealing demo and a trustworthy record lies in the details a buyer can check after the demo ends.

## Patel's path into document software

Patel [describes himself](https://rohit-patel.com/) as Ndoc's founder and a former director at Meta Superintelligence
Labs. He says he spent eight years building AI at Meta and had earlier worked with executives of private-equity-owned
businesses. TechCrunch independently reported the Meta departure and Ndoc launch, but the details of his earlier
business work in his biography remain his own account. A
[public LinkedIn departure post](https://www.linkedin.com/posts/rohitpat_its-been-a-blast-working-on-cool-stuff-at-activity-7494164794116128768-GBXn)
records his earlier decision to leave after about 7.8 years. It should not be mistaken for a launch date or a report on
how Ndoc works.

What can be checked more directly is the research Patel helped publish while at Meta. In
[GIM](https://arxiv.org/abs/2605.18663), first-authored with Alexandre Rezende and Steven McClain, the researchers built
820 original problems, including 615 public and 205 private items, to test whether models can integrate different kinds
of reasoning in a single task. The paper reports results across 22 models and 47 reporting configurations. It argues
that a model's thinking budget and configuration can materially change a score. That is a research finding within its
evaluation design, not a guarantee about any document generator Patel later founded.

An August [Modality Maturity Index paper](https://arxiv.org/abs/2608.26317), first-authored by Patel with Dieuwke Hupkes
and Sloan Strader, asks whether systems marketed as broadly multimodal can produce the right combinations of text,
images, audio, video, and documents. Its 893 questions use human-authored rubrics. The authors report low scores for
whether the expected output modalities are present in five models they evaluated, and 70.8% agreement between an LLM
judge and human annotators in a separate experiment. Those numbers are the paper's reported results under a particular
test; they are not independent certification of all frontier models.

The paper also separates presence from correctness. A system may be unable to return the requested type of artifact at
all, which makes a score on the artifact's quality premature. That distinction follows Patel into document software.
Before asking whether an AI-written presentation is persuasive, a buyer should see whether the requested dataset,
calculation, citation, and chart are actually present and connected. After that comes the harder question of whether
each part is right. A polished Stage view can conceal a missing Model step just as a fluent multimodal answer can
conceal an absent modality.

This research record is relevant because it shows a recurring interest in what a model actually returns, how a task is
scored, and where a confident label can conceal a narrower capability. It does not prove that Ndoc catches an incorrect
formula or preserves a chain of evidence. The intellectual connection is an inference from public work and product
design. Patel's own explanation is simpler: he says he had stopped using traditional office tools, was writing in
Markdown backed by Python, and saw colleagues sending React dashboards instead of slides. His
[site](https://rohit-patel.com/) presents Ndoc as a way to remove the handoff work among those formats. That is a
founder's diagnosis, worth testing against the habits and controls of the organizations he hopes to serve.

## Three surfaces around one decision

Stage, Narrative, Model: Patel's names for the three parts of an Ndoc document. On his
[product description](https://rohit-patel.com/), Stage holds live slides, dashboards, and small interactive apps.
Narrative holds the written argument, citations, figures, and numbers linked to a Python run. Model holds datasets and
scripts, displayed as a flow diagram. TechCrunch's interview describes the same arrangement and reports Patel's example
of uploading a dataset, asking for an analysis, and generating a written account of the findings. The two sources align
on the intended design. Neither independently tests the delivered software.

Consider a hypothetical procurement committee comparing suppliers. Its analyst calculates a cost per completed order and
puts a savings estimate on a slide. A reviewer asks whether returns, shipping, and implementation labor were included.
In an ordinary handoff, the answer may be spread across a spreadsheet, a notebook, a slide deck, and a message
explaining which version is current. Ndoc's design proposes that the reviewer can move from the presented estimate to
its narrative assumptions and then to the code and data behind it. The hypothetical illustrates the question a buyer
should ask; it is not a reported Ndoc customer case.

The connection is useful only if it survives change. If a source table is replaced, does the displayed estimate
recompute? Does the narrative mark which sentences are linked to calculations and which were written as judgment? If a
reviewer edits the assumption, can the team identify the previous value, author, and time? Patel's diagram of data,
analysis, and story suggests a path through these questions. A visible path is a product feature claim. A dependable
path requires behavior under revisions, permissions, failed runs, and conflicting versions.

The hardest handoff may come after a correction. Suppose the supplier's freight cost was entered in the wrong currency
and the manager approved the first slide. Fixing the code and recalculating the number is necessary, but so is finding
every sentence, chart, comment, and exported copy that used the old figure. If Ndoc's three surfaces share a dependency
graph, it might flag those places automatically. Patel's public description does not establish that behavior. A pilot
should deliberately introduce this kind of error, because a clean first run is the easiest case for any integrated
workspace.

There is a second audience besides the analyst. A director may never read a Python file. In the TechCrunch interview,
Patel suggested that a user could ask the assistant to explain a script or point to the line containing a formula. That
makes the code approachable, but the explanation itself can be wrong. A reviewer must still compare the explanation with
the actual executable step and the input data. The best version of the design would let a non-programmer inspect a
decision without pretending that conversational reassurance is a substitute for verification.

## An inspectable script is a beginning

What does a visible script actually reveal? It lets a reviewer read a transformation. It does not confirm that the input
table was the intended version, that a generated sentence describes the result accurately, or that someone else can
reproduce the calculation next month. Ndoc's proposed layout could help a reviewer investigate each step. A flow diagram
alone cannot settle them.

The [W3C PROV ontology](https://www.w3.org/TR/prov-o/) is a useful conceptual check. Provenance represents entities,
activities, and agents so that a record can say what was used, what produced something, and who or what was involved.
Ndoc has not claimed conformance to that standard in the material reviewed here. The standard clarifies what a serious
evidence chain would need to represent: a specific dataset version, a specific transformation, the result, and the
relationship among them. A file that includes code but lacks immutable input identifiers may be readable while still
being impossible to reproduce.

An independent [FLARE spreadsheet benchmark paper](https://arxiv.org/abs/2506.17330) found that language models it
tested could do straightforward spreadsheet tasks but often produced plausible wrong answers in more complex, multistep
work. It is one study, published in 2025, and it did not test Ndoc. Its relevance is the failure mode: an answer can
look polished enough for a slide while being wrong at the level of formula logic or data handling. That is precisely
where a trace from claim to computation would help a reviewer catch trouble.

Even correct code can produce a misleading figure if the question was framed badly. The procurement analyst might divide
total spend by completed orders when the business decision requires cost per delivered order after returns. Every line
of Python could execute perfectly; the metric would still answer the wrong question. The narrative layer therefore has
work to do beyond explaining syntax. It must expose the business definition, time window, exclusions, and
counterfactual. If those choices are buried in a prompt or a private chat, a visible script will create a false sense of
completeness.

For a pilot, the practical test is to seed a dataset with known edge cases and then ask different users to interrogate
the same result. Can a reviewer trace a chart value back to the exact row set and transformation? Can they see a warning
when a required field is missing? If a colleague changes the definition, do the slide and text show the revision instead
of silently inheriting a new number? These are proposed evaluation tasks, not claims that Ndoc already passes them. They
would turn Patel's central idea into a falsifiable procurement question.

## A file that survives its vendor

A format becomes useful when a reader can leave its maker behind. Patel's [site](https://rohit-patel.com/) says an Ndoc
document uses familiar materials such as Markdown, React, Parquet, Python, and JSON and can be exported as a single
self-contained `.ndoc.html` file. It calls the format's specification open under Apache 2.0. In the TechCrunch
interview, Patel described the specification as something he planned to open source so that other developers could make
compatible applications. The two descriptions differ in tense. As of this review, a public specification and a
representative exported file were not located or independently inspected. That is an access limit, not proof that they
do not exist.

An HTML file that opens in a browser would be a useful exit route. Opening is only the first test. A buyer would want to
know whether the exported document preserves tables, charts, annotations, code, data licenses, accessibility, and the
ability to recalculate a figure. Some interactive views need JavaScript or external assets. A self-contained archive
should disclose which dependencies are embedded and what happens when a browser changes its security rules. If it
contains executable code, an organization will also ask how that code is isolated and who is allowed to run it.

Portability has at least three levels. First, a reader can view the final result without an Ndoc account. Second, a
reviewer can inspect the underlying materials without the live service. Third, another program can edit and recompute
the document without losing meaning. Patel's broad open-format proposal points toward the third level. The public
evidence currently supports his intention to pursue it, not proof of interoperable implementations. An independent
parser, a versioned schema, a sample file, and a documented migration path would make the promise easier to judge.

[OpenAI's Space help page](https://help.openai.com/en/articles/20001549-getting-started-with-space-in-chatgpt) describes
sharing controls for its pages, with plan and administrator restrictions. Those are collaboration features within a
service; the page does not promise that every chart and formula can be moved into another editor intact. Microsoft and
Google have their own file and workflow ecosystems. Patel could make an exit test visible before a company builds years
of documents around his format. A public sample would give that promise some weight.

![An editorial illustration of layered data, computation, narrative, and presentation cards connected by a traceable path, with one unresolved link highlighted.](/images/articles/rohit-patel-ndoc-inspectable-ai-document/inside-v1.jpg)

_AI-generated editorial illustration._

## Incumbents already see the same problem

On [August 25, Microsoft said](https://learn.microsoft.com/en-us/microsoft-365/copilot/release-notes) that editing with
Copilot in Excel could run Python for analysis and put the result in a workbook. In September it added links from
Copilot responses to changed workbook locations. Those are Microsoft's release statements, but they show an incumbent
working on a path from an AI action to a visible artifact. Patel framed Ndoc in the TechCrunch interview as a
replacement for a patchwork of spreadsheets, documents, slides, business intelligence tools, and copied AI answers. The
contest is already more complex than a new file against old office software.

Google's
[September Sheets canvas announcement](https://workspace.google.com/blog/product-announcements/turn-your-data-into-action-6-mini-apps-you-can-create-with-sheets-canvas)
describes mini apps generated from sheet data and synchronized with underlying cells. It says standard file permissions
govern sharing. That is a company account of an available feature for specified plans; it does not establish that every
generated chart can be audited back to a calculation. Still, a buyer comparing Ndoc with Sheets cannot assume Google has
only a chatbot next to a grid. The incumbent is trying to make the spreadsheet a presentation surface, too.

[OpenAI's current Space documentation](https://help.openai.com/en/articles/20001549-getting-started-with-space-in-chatgpt)
says users can organize pages and uploaded files, collaborate on documents, and create charts and trackers in pages.
Slides are rolling out to eligible accounts; Sheets are listed as coming soon. The page also notes that sharing depends
on account type, organization settings, and in some cases region. This is an adjacent product rather than an exact Ndoc
replica. It matters because the unit of collaboration is becoming a contested design choice across AI and office
vendors. Patel must persuade a team to adopt a new file and workflow while larger products add pieces of the same
experience inside accounts that teams already use.

An existing office suite has an advantage beyond feature count. It already holds the team's identity system, permission
groups, document history, retention policy, comments, and habits. A new product may create a more coherent artifact, yet
its pilot must cross these administrative boundaries. If a reviewer outside the company can open an export but an
internal compliance team cannot set retention, the first benefit will not settle the purchase. If a connector imports an
Excel model but drops named ranges or comments, the demonstration may hide the migration cost. These are potential
failure points to test, not observed defects in Ndoc.

There is a reasonable objection to Patel's redesign: keeping work in familiar files may be safer for a team that already
knows how to review them. A finance group may have controls around approved Excel templates and a legal team may insist
on a tracked Word revision. Even a technically elegant new artifact can make an audit harder if it falls outside those
controls. The incumbent approach, improving AI inside existing formats, could win for such buyers without offering the
clean unified record Patel wants. Ndoc would need to demonstrate a net reduction in review effort after migration and
governance costs, not simply a shorter path from prompt to slide.

The smaller firm's advantage is also concrete. It can design the document and the AI action together, rather than
fitting generation into a decades-old grid or slide metaphor. Patel says his own work had already moved to Markdown,
Python, and React. For teams that work the same way, the design may reduce the glue between an analysis notebook and a
meeting deck. For teams whose decisions rely on approved spreadsheet templates, the same design may ask them to change
too much at once. The adoption case therefore depends on the first job Ndoc can perform better under a real review
process, not on a promise to replace Office in the abstract.

## Pilot enthusiasm is not a measured outcome

One pilot can tell a founder where users pause, return, or ask for help. TechCrunch reported that Ndoc was conducting an
enterprise pilot and opening a limited alpha as of October 27. Patel said early users were most excited to see their
work end to end in one place. That is useful qualitative feedback from the founder's account. The report does not name a
customer, provide a retention curve, show a completed migration, or measure the time a reviewer needed to verify a
result. It also does not say whether the pilot has passed security review or whether a decision made with Ndoc held up
when challenged.

The distinction matters because several different successes can look similar in an early interview. A pilot user can
admire a dashboard and still export the final numbers to a spreadsheet for sign-off. A team can create documents quickly
while reviewers spend longer checking generated claims. A user can open a shared file once without becoming a repeat
collaborator. None of these possibilities contradicts Patel's report of interest. They show why a serious outcome needs
a denominator, a comparison workflow, and a time period.

For a buyer, the first comparison might use one existing monthly report, not an invented greenfield example. Record the
time required to import its data, reproduce the current accepted result, make a routine change, explain an unexpected
value, and export an archive. Run the same task in the incumbent workflow and in Ndoc with the same staff and source
data. Count corrections, lost information, reviewer questions, and steps requiring a specialist. A faster first draft
with a slower sign-off is a mixed result. A shorter audit with a traceable correction is stronger evidence of Patel's
actual thesis.

The test also needs a second author. Can an analyst create the work, a manager inspect it, and a third person edit it a
week later without a private explanation from the creator? Can the manager distinguish a citation to an external source
from a number produced by a script? If the generated narrative paraphrases an assumption incorrectly, will a reviewer
notice the mismatch? An enterprise trial can answer those questions without publicizing private data. It could publish
anonymized task descriptions, measured times, error categories, and the handling of failed runs. No such independent
Ndoc evidence was available in the reviewed sources.

Patel said he did not want to raise money until he had evidence people loved the product. That is a founder's stated
threshold, not a published financing plan or proof of product-market fit. A three-person team may benefit from staying
focused while the file model matures. It also bears the burden of supporting integrations, security review, and customer
service with very few people. Both sides of that tradeoff are visible from the reported team size and launch stage;
neither predicts the outcome of the pilot.

## Cost claims need a real workload

The price of a model call is one line on an enterprise document's bill. Patel told TechCrunch that Ndoc uses and
fine-tunes a mixture of open-source models and that the platform costs considerably less to operate than alternatives
based on frontier models. He also described a planned price tied to usage and tokens. Neither claim came with a public
workload definition, measured inference cost, or price sheet in the material reviewed. A buyer should treat them as
design and pricing intentions until the vendor shows an invoice and a repeatable task. The model's license and size
alone do not determine the total cost.

Suppose a document starts with a large dataset, generates a model, updates a dashboard after every edit, and lets
several colleagues ask questions about its lineage. The bill may include retrieval, execution, chart rendering, storage,
repeated inference, and human review. A cheaper model call can be overwhelmed by more calls or by manual repair.
Conversely, a well-designed cache and a stable document graph might reduce repeated work. The only meaningful comparison
holds the source data, accuracy requirement, collaboration pattern, and number of revisions constant. Patel's low-cost
claim is plausible as a hypothesis; its size and durability remain unmeasured in the public record.

Token pricing also changes user behavior. If a reviewer is charged for asking the system to explain each formula, the
very inspection that differentiates Ndoc may become a metered action. A predictable enterprise plan might absorb that
cost, but the plan has not been described in enough detail to assess. Buyers should ask whether viewing an exported
record is free, whether recomputing one is charged, and whether a colleague without an account can verify calculations.
The terms would reveal whether the file is truly a shared unit of work or a convenient doorway back into a paid service.

The evaluation papers offer a caution about apparent economy. [GIM](https://arxiv.org/abs/2605.18663) reports that
configuration and thinking budget change measured capability within model families. A cheaper run may be sufficient for
a simple summary and inadequate for a multistep analysis. [MMI](https://arxiv.org/abs/2608.26317) likewise separates the
presence of an expected output modality from its correctness. Those results do not choose Ndoc's model stack. They
suggest the test an experienced evaluation researcher should recognize: compare cost only at a stated quality level, and
publish failures as well as median successes.

## Trust runs through access and change

A file can be easy to share and dangerous to forward. One document containing data, analysis, and presentation may
simplify a handoff while concentrating sensitive material. TechCrunch reports Patel's claim that Ndoc can maintain
context across a person, document, team, and company. That could help collaborators avoid repeating instructions. It
raises specific questions about who can see each layer, how long context is retained, whether one team's data can
influence another's answer, and how an administrator deletes it. No audited enterprise-control record was found in the
sources reviewed for this article. The absence of a public record is a question for diligence, not a claim of insecure
operation.

The exported file deserves the same scrutiny. If it embeds a full dataset, it may be more portable than a link and less
appropriate to forward casually. If it omits the dataset, its result may not be independently reproducible. An
organization needs a deliberate choice between a view-only artifact, an inspectable internal archive, and an editable
copy. It also needs to know whether each choice preserves permissions and attribution. A public sample with
non-sensitive test data would let potential buyers study those tradeoffs without asking the founder to disclose a
customer's records.

Version history is another test of Patel's "one place" argument. A team can agree on a single file at 9 a.m. and diverge
by noon if two people branch the model or if a generated narrative is edited without recalculating its chart. A credible
system should identify the source of each published value and show which parts are stale after a change. It should say
whether a share link points to a living document or a fixed revision. The ability to restore an earlier version is
useful, but a reviewer also needs to know what changed and why. AI edits make these familiar document-management
questions urgent.

Office incumbents face the same questions, and their current controls may be uneven. Microsoft's Copilot release notes
refer to existing security and execution controls for Python in Excel. Google's Sheets canvas announcement points to
standard file permissions. OpenAI's Space help page describes plan and administrator limits on sharing. These statements
are useful comparison points, not a finding that the products have equivalent governance. A buyer should map each claim
to an actual control in the plan and region it uses, then put Ndoc through the same review. The strongest Ndoc answer
would be a working file, an admin policy, and an auditable change log that survive contact with a real team's process.

## Proof in ordinary work

Start with a report the company already signs. Give the team a messy but lawful dataset and a decision it has to make.
Ask it to build a number, explain the assumptions, show a colleague where the number came from, correct an error, and
hand the record to someone outside the original tool. Then repeat the exercise after the data changes. If Ndoc reduces
the total effort while preserving the trail, the file design has earned a stronger claim than a launch interview can
provide. If the evidence trail disappears on export or the review depends on the author remembering a prompt, the
central design needs more work.

Five public artifacts would make that experiment easier to assess: a versioned specification for `.ndoc.html`, a
harmless sample export, a documented import-and-edit round trip, a pilot evaluation with both time and error measures,
and a clear statement of access and retention controls. These are proposed milestones, not promises Patel has made. They
would be more informative than a generic user count because they test the proposition that distinguishes Ndoc from a
capable incumbent add-on. They would also let outside developers and reviewers decide whether "open format" means
browser-readable presentation or genuine interoperability.

The timing of those artifacts matters more than the announced target for a beta. TechCrunch described a limited alpha, a
beta planned in weeks, and a full launch intended for next year. Plans can change. The useful follow-up is to check what
actually becomes available, who can test it, and whether the claims in the October pitch can be reproduced under
ordinary business constraints. A company need not be fully launched to show a sample file or publish a security model.
It does need those records before a buyer can treat its portability and trust claims as established.

Imagine the procurement manager opening the same savings estimate six months later, after the analyst has left and
Ndoc's interface has changed. Can the manager find the source rows, rerun the calculation, and explain why the number on
the final slide differs from the first draft? Patel's research papers show how seriously he has treated measurement in
another domain. The pilot has yet to show that a document can answer this ordinary, inconvenient question. It is the
test that would make his new file worth trusting.

## Continue reading

- [Databricks Acquired Row Zero for Work That Still Ends in Cells](https://digidai.github.io/2026/09/29/databricks-row-zero-ai-spreadsheet-work/): Compare a data platform attempt to keep AI analysis and spreadsheet work together.
- [OpenAI Put a Dashboard Builder Inside ChatGPT Work](https://digidai.github.io/2026/09/11/chatgpt-work-data-agent-dashboard-labor/): Examine the labor behind a shared AI workspace and its data agent.
- [Can HR AI Evidence Survive a Vendor Switch?](https://digidai.github.io/2026/05/11/hr-ai-evidence-portability/): See why exporting an AI-assisted record does not by itself preserve usable evidence.
- [AI Safety Tests Reached Systems They Did Not Own](https://digidai.github.io/2026/09/01/ai-safety-tests-live-systems/): Apply live-system evaluation discipline to an AI product claim.