Rohit Patel Wants the AI Document to Show Its Work

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, 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, Google has announced interactive Sheets canvas apps, and OpenAI’s Space documentation 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 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 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, 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, 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 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, 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 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 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 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 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.

AI-generated editorial illustration.

Incumbents already see the same problem

On August 25, Microsoft said 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 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 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 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 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.