Notizie

Liquid AI has released Antidoom, an open-source method that targets a common failure mode in reasoning models. That failure mode is the doom loop. In a doom loop, a model emits a span. It then repeats that span again and again. The output continues until the context window is exhausted. Small reasoning models are more prone to this, especially on long thinking traces and hard problems. On an early checkpoint of LFM2.5-2.6B, 10.2% of completions on hard math and coding prompts produced repetitive loops. After Antidoom training, that rate fell to 1.4%. Eval scores improved across the board, attributable entirely to the reduced looping. TL;DR Antidoom reduces doom loops by retraining only the first loop-start token. FTPO spreads probability across multiple coherent alternatives, not one replacement. LFM2.5-2.6B looping fell 10.2% to 1.4%; Qwen3.5-4B fell 22.9% to 1%. The pipeline runs in a few hours, and the full stack is open source. What is Antidoom? Antidoom is a targeted fix, not a broad sampling change. It finds the exact token that begins a loop. It then trains the model to prefer coherent alternatives at that single position. The rest of the distribution stays largely untouched. The method adapts Antislop. It trains on chosen/rejected pairs that represent a single completion token. The training algorithm is Final Token Preference Optimization (FTPO), which is similar to DPO. The training teaches the model nothing new about math or code. It clears the looping that blocked answers the model could already produce. Anatomy of a Doom Loop Liquid AI team attributes doom loops to three mechanisms working together: Mechanism 1: overtrained tokens plus uncertainty. Some tokens are more likely to be selected in general. Well-known examples in the wild include ‘delve’ and ‘testament.’ Liquid AI team notes this can trace back to synthetic data in the training set. In reasoning traces, high-prior continuations often include discourse markers such as ‘Wait’ or ‘Alternatively.’ These tokens are not inherently bad. They can mark a useful change of strategy, a verification step, or a branch. When the model is uncertain or stuck, they instead become attractive fallback continuations. For an early LFM2.5-2.6B checkpoint, the most common loop-starting tokens were the following. Token Share of loop starts the 11.39% So 4.51% Alternatively 3.22% Wait 2.56% But 2.46% Mechanism 2: prior context reinforces the loop. Each repetition pushes every token in the span toward probability that Duan et al. study this in their work on circular reasoning. They link it to a “V-shaped” attention pattern. They find that semantic repetition precedes textual repetition. Mechanism 3: greedy sampling. Reasoning models usually run at low temperature for stable, reproducible traces. At temperature 0, the most likely token is always selected. A locally reinforced loop then has no exit. Liquid AI reports significant looping even at temp=0.67. Lower temperatures exacerbate the problem. How Antidoom Locates the Failure Antidoom generates completions on a prompt mix designed to elicit looping, at low temperature. That mix ships as the LiquidAI/antidoom-mix-v1.0 dataset. A loop is detected when a section repeats at least four times, over at least 60 characters. The method then targets the first token of the first repeat. At that position, it takes the base model’s top-k log-prob alternatives. It filters short or non-alphanumeric noise. It keeps up to 20 plausible substitutes as chosen tokens. Each training row is a tuple of prompt prefix, one rejected token, and one or more chosen tokens. The chosen and rejected distributions are regularised before training. Otherwise a few culprits like Wait, So, and the would dominate and over-suppression would degrade reasoning. The detection rule itself is simple to state in code. The snippet below is illustrative. Copy CodeCopiedUse a different Browser # A loop = a unit repeating >=4 times, spanning >=60 characters. # Returns the index of the first token of the first repeat (the target), else None. def find_loop(text, min_repeats=4, min_chars=60): n = len(text) for span in range(1, n // min_repeats + 1): start = 0 while start + span * min_repeats <= n: unit = text[start:start + span] repeats = 1 pos = start + span while text[pos:pos + span] == unit: repeats += 1 pos += span if repeats >= min_repeats and span * repeats >= min_chars: return start + span # first token of the first repeat start += 1 return None Each detected loop then becomes one training row. The structure is a simple tuple. Copy CodeCopiedUse a different Browser # One FTPO training row, per the post’s [prefix, rejected, chosen] format. row = { “prompt”: prefix_up_to_the_loop, # text before the first repeat “rejected”: ” Wait”, # the single token that started the loop “chosen”: [” So”, ” Since”, ” The”, ” Therefore”], # up to 20 alternatives } Final Token Preference Optimization (FTPO) FTPO is a preference-optimization algorithm similar to DPO. A training sample has a prompt, a chosen continuation, and a rejected continuation. It is built to change a handful of tokens, with minimal disturbance to the model otherwise. FTPO differs from DPO in four ways: Final token training: It trains only the trailing token of a sequence that is midway through generation. Multiple chosen tokens per sample: It spreads probability across a group of alternatives, so one overtrained token is not simply replaced by another. KL-like loss in logit space: It omits the softmax and computes divergence from reference in logits, avoiding pressure on unrelated tokens. Two-part regularization: Chosen and rejected logits move more freely, while the remaining vocab stays tightly constrained. In the Antidoom implementation, the model trains for one epoch with LoRA. High LoRA ranks of 128-256 gave the best results. Training covers all attention and MLP projections, plus lm_head. Learning rates land around 4e-6 to 2e-5. Training uses early stopping on chosen_win, the share of samples where chosen tokens beat rejected. Stopping at chosen_win=0.35 cut doom-loop rates from 20-30% down to 1-2%. Training longer tended to degrade the model. For the early LFM2.5-2.6B checkpoint, training-set generation took about one hour on 8x MI325 GPUs. Training then

Baek, a 35-year-old manager at the South Korean semiconductor titan SK Hynix, was enrolled in Sunoo, a matchmaking company based in Seoul, a year ago. In a move typical of anxious South Korean parents, his mother signed him up, hoping to find a good wife for her son. Lately, says Baek (who asked to be referred to by his last name to protect his privacy), he and his coworkers are having better luck finding dates than they used to, perhaps because of the dazzling bonuses they just got. Flush with eye-popping profits from the AI chip boom, SK Hynix struck a landmark deal last year with its labor union to pay out 10% of operating profits to employees, which translates to an extra $476,000 per employee this year. A similar agreement and sizable lump sum followed for Samsung workers this May. With their newfound wealth, chip workers like Baek have become the most sought-after bachelors and bachelorettes in South Korea. “I have a coworker who’s perpetually going on blind dates, and he’s been getting so many recently,” says Baek. “For the past few months, I’ve been getting many blind dates too, perhaps because of the bonuses I got.” Lately, young South Koreans joke online that the best outfit to wear on a blind date is an SK Hynix uniform.  The AI chip boom is changing the social fabric of South Korea by minting a new elite of “silicon-collar” workers earning about 20 times as much as the average South Korean. Although it’s helping some chip workers to find relationships, it’s also fueling fears of a deepening wealth disparity—and a loud public debate about inequality. Love in the time of chips South Korea is the epicenter of the chip boom fueling the AI race. Samsung and SK Hynix supply the vast majority of the world’s high-bandwidth memory (HBM) chips, which power Nvidia’s AI accelerators—the GPUs used to train AI models. As AI companies spend hundreds of billions of dollars on building data centers around the world, demand for HBMs is rising beyond what suppliers can keep up with, driving their prices to unprecedented levels. Samsung and SK Hynix are raking in record profits as a result.  South Korea’s economy now orbits the two chip giants. In May, both companies topped $1 trillion in market value. And chip exports helped fuel a 1.7% surge in South Korea’s gross domestic product in the first quarter of 2026. South Korea’s main equity index, Kospi, has nearly tripled over the past year, becoming the best-performing market in the world. Swimming in cash, chip workers are going on shopping sprees in department stores near the “semicon belt” fabs—splurging on everything from lavish furniture and electronic appliances to jewelry and watches. They’re also snapping up homes near the commuter-shuttle routes that ferry workers to campus. And they’re shelling out for matchmakers. “Quite a lot of people ask me if I can introduce them to chip workers,” says Lee Sung-mi, a matchmaker at Sunoo, who has been playing Cupid for chip workers for years. “In fact, people who once rejected them are asking to be matched with them again, now that their salaries and bonuses have shot so far above what everyone else earns.” One woman who lives in Gangnam, a ritzy district in Seoul lined with luxury high-rises and designer boutiques, previously turned down a chip worker at SK Hynix because his fab was too far out in Icheon, a rural city about 50 miles southeast of Seoul that’s dotted with rice farms and manufacturing plants. But in May, she asked her matchmaker to set them up again. They’ve now been dating for a month.                                                                                                                                                                                                                                                                                                                                                                                                                              In South Korea, matchmaking companies evaluate their clients on a long list of criteria such as education, job, income, looks, and family background, including whether their aging parents have saved enough for retirement. In an economy where housing prices and child care costs are soaring, competition for jobs is fierce, and the social safety net is thin, a good job is the ultimate dating credential—all the more coveted at a time when many young South Koreans are forgoing marriage and children altogether, seeing family life as an unaffordable dream. Every client at Sunoo gets a spouse rating, determined by an algorithm that assigns scores for each criterion. Since their hefty bonuses were announced, the job ratings of Samsung employees have risen from 80 to 84, while those of SK Hynix employees climbed from 78 to 82. Scores above 90 are reserved for doctors and lawyers. Long prized as paragons of prestige and wealth, they’re now close to being overtaken by chip workers. A score of 99, the highest possible rating, is earmarked for heads of state.   Their new status is reshaping how chip workers themselves approach dating. “Chip workers from Samsung and SK Hynix are enrolling in our services because they feel more financially ready,” says Lee. “They’re also becoming pickier, as they feel like they’re now in a good position. The women want to meet men with higher incomes and better jobs, and the men want to meet younger and better-looking women with better jobs.”  An SK Hynix engineer in her 40s, who was once desperate to get married as soon as possible, started turning down men she would’ve dated before the chip boom. Lately, showered with more matches, she’s been sifting through her suitors more carefully. “She now has peace of mind and wants to take her time to meet someone better,” says Lee. A mixed blessing While chip workers enjoy the fruits of their labor, the bonus bonanza is stoking anxieties among other South Koreans. “When wealth disparity is no longer a mere difference of income but, rather, a difference in identity … it can fuel social conflict,” says Se-eun Jung, an economist at Inha University.  Earlier this month, the Bank of Korea warned that the chip boom will create a “K-shaped” economy, where a handful of workers race ahead while everyone else falls behind. The windfall, the

This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here. OpenAI CEO Sam Altman’s oft-discussed promise that Americans will share in the wealth AI creates was in the news again last week. On Thursday, the Financial Times reported that Altman is in talks with President Trump about giving the US government a 5% stake in OpenAI. In some ways, Altman’s plan is old news. He wrote about a more radical version of this back in 2021, proposing that all companies above a certain valuation (not just AI companies) pay 2.5% of their market value each year into a fund that sends Americans annual disbursements. In April this year, OpenAI described a narrower proposal that closely resembles what Altman is reportedly discussing with Trump now. And the notion has broad political appeal: Senator Bernie Sanders has proposed giving Americans a 50% stake in top AI companies. What’s the logic here? For would-be recipients, it’s twofold. First, AI learns directly from human-generated work—books, movies, art—but AI companies generally never pay the authors of that work. A free equity stake could serve as a form of belated compensation. Second, the payout could mitigate the widespread anxiety that AI will cause a collapse of the labor market (even if economists disagree) by providing a safety net.  How large a safety net is up for debate. Details of OpenAI’s latest proposal are sparse, but let’s say the government were to distribute this equity stake directly to Americans. After its funding round in March the company was valued at $852 billion, making a 5% stake in OpenAI worth about $42.6 billion today (the company is reportedly delaying its IPO until it can reach a $1 trillion evaluation, a tall order given that it’s spending heavily on data centers and still has not turned a profit). Distributing that $42.6 billion equally among the roughly 133 million American households would give each about $320 in equity. But if it were to operate like other wealth funds, the government would not give equity directly to Americans but rather let the fund grow and then share a portion of the returns with everyone, perhaps delivering a bigger payout, if and when AI companies can ever start sustainably turning a profit. If this dividend does materialize, what’s in it for tech companies? Altman might hope the promise of payouts could help swing public opinion a bit more back toward AI companies. (A majority of Americans don’t trust companies to use AI responsibly and oppose construction of data centers in their area, and half are more concerned than excited about the increased creep of AI into their daily lives.) But the bigger prize for OpenAI might be that the Trump administration loves making tech deals—like its equity stake in Intel and its share of Nvidia’s sales to China, among others.  Staying on the administration’s good side is pretty essential for AI companies right now (just ask Anthropic). It could mean not having your models deemed a supply chain risk, or getting more help from the White House in stopping your rivals from China.  My main takeaway is that these plans currently function more as a story than a policy. Altman has been talking about some version of this idea for five years and reportedly pitched it to President Trump soon after he took office, yet there is still little indication that a concrete plan is taking shape. The more ambitious proposal from Sanders is even less likely to gain traction. But what these plans do reveal is just how up for debate the future of AI still is. Altman drew inspiration for his plan from the Alaska Permanent Fund, which was set up in the 1970s to give Alaskans a share in oil profits. The idea was based on two premises: that oil is a shared resource, and that eventually it will run out. Altman seems happy to concede the first claim about AI. But he’d balk at the second, having promised that AI will generate extraordinary wealth for decades to come. Whether Americans ever receive a check is beside the point; the proposal’s real purpose may be to convince them that the AI boom will be large enough to share.

Most enterprise data still sits inside PDFs, scans, and slide decks. Large language models and agents cannot use that data until it becomes structured JSON. Open-source document extraction has become the standard way to do that conversion on your own hardware. Two different problems hide under the phrase ‘PDF to JSON.’ The first is schema-driven extraction: you define fields, and a model fills them with values. The second is document parsing: a model reconstructs the page into structured JSON or Markdown. Most teams need one, sometimes both. Choosing the wrong category costs real time. Open weights matter here for cost and privacy. Proprietary APIs can cost thousands of dollars per million pages, and they require sending documents off-premise. Local models remove both constraints. Below are the models and toolkits worth evaluating, grouped by what they actually do. Two categories, one phrase Schema-driven extraction takes a document and a JSON schema, then returns values for your fields. Use it for invoices, forms, contracts, and receipts, where you know the fields in advance. Document parsing reconstructs the document itself. It detects layout, reading order, tables, formulas, and code, then exports JSON or Markdown. Use it to prepare clean corpora for retrieval-augmented generation (RAG) and agents. Category 1: Schema-driven structured extraction Datalab lift lift is a 9B vision model from Datalab, the team behind Marker and Surya. You pass a JSON schema, and lift returns JSON that matches it. Schema-constrained decoding guarantees the output is valid JSON. The model is built on Qwen 3.5 and runs locally through Hugging Face or remotely through a vLLM server. It handles multi-page documents in a single pass, including values that span pages. It ships a CLI, a Python API, and a Streamlit ‘Schema Studio’ for building and testing schemas. Copy CodeCopiedUse a different Browser pip install lift-pdf # Start the vLLM server, then extract to your schema lift_vllm lift_extract input.pdf ./output –schema schema.json Copy CodeCopiedUse a different Browser from lift import extract result = extract(“document.pdf”, “schema.json”) if result.extraction is not None: data = result.extraction # dict matching your schema On Datalab’s 225-document benchmark, lift reaches 90.2% field accuracy at 9.5s median latency. It leads NuExtract3 (81.5%) and Qwen3.5-9B (76.3%) on field accuracy. It trails Gemini Flash 3.5 (91.3%) and the hosted Datalab API (95.9%). Note that full-document accuracy stays low for all local models, with lift at 20.9%. Getting every field right in one document remains hard. The code is Apache-2.0. The weights use a modified OpenRAIL-M license, free for research, personal use, and startups under $5M in funding or revenue. Commercial self-hosting needs a license, and the weights cannot be used competitively with the Datalab API. NuMind NuExtract 3 NuExtract 3 is a 4B vision-language model from NuMind. It unifies two tasks in one model: structured extraction (document to JSON) and content extraction (OCR to Markdown). You provide an input and a JSON template describing the fields you need. The model is trained with reinforcement learning to add extraction-specific reasoning, which you can switch on or off per request. NuExtract 3 is multimodal, multilingual, and based on a Qwen backbone. It serves through vLLM with an OpenAI-compatible API, and a Python SDK is available via pip install numind. NuMind positions it as a reference open model for both structured and content extraction at its size. Check the model card for exact license terms before commercial use. Category 2: Document parsing to structured JSON and Markdown IBM Docling Docling started at IBM Research and is now hosted by the LF AI & Data Foundation. It parses PDF, DOCX, PPTX, XLSX, HTML, images, and more. Output formats include Markdown, HTML, lossless JSON, and DocTags. Its core is the DoclingDocument representation, which preserves layout, reading order, tables, and formulas as LaTeX. Docling runs locally for air-gapped environments. It integrates with LangChain, LlamaIndex, Crew AI, and Haystack, and ships an MCP server and a Docling Serve mode. The project carries a permissive MIT license. IBM also offers a managed version through watsonx. IBM Granite-Docling-258M Granite-Docling-258M is a compact 258M vision-language model from IBM. It performs one-shot document conversion inside Docling pipelines. Despite its size, it handles OCR, layout, tables, code, and equations, and outputs DocTags. On an A100 GPU, it averages roughly 0.35 seconds per page. The model builds on the Idefics3 architecture, with a SigLIP2 encoder and a Granite 165M language backbone. It is released under Apache 2.0. IBM states it is built for document conversion, not general image understanding. OpenDataLab MinerU MinerU, from OpenDataLab and Shanghai AI Laboratory, converts PDF, image, DOCX, PPTX, and XLSX inputs into Markdown and JSON. It pairs a processing pipeline with a vision-language model. The current model, MinerU2.5-Pro, targets high-resolution parsing of complex layouts, including cross-page tables and charts. MinerU recently changed its license. It moved from AGPL-3.0 to the “MinerU Open Source License,” a custom license based on Apache 2.0 with additional conditions. That change lowers friction for commercial deployment. Datalab Marker Marker is Datalab’s pipeline for converting documents into Markdown, JSON, chunks, and HTML. It supports PDF, image, PPTX, DOCX, XLSX, HTML, and EPUB. It formats tables, forms, equations, inline math, links, and code. An optional –use_llm flag adds a language model to improve tables and forms. On the third-party olmOCR-Bench suite, Marker scores around 76.1. Its code is GPL-3.0, and its model weights use a modified AI Pubs OpenRAIL-M license. That weight license is free for research, personal use, and startups under $2M in funding or revenue. Datalab’s managed platform now runs a newer OCR model, Chandra, which is Apache-2.0 and outputs HTML, Markdown, and JSON. Ai2 olmOCR 2 olmOCR 2 is a 7B OCR-specialized vision-language model from the Allen Institute for AI (Ai2). It converts PDFs into clean text and Markdown while preserving reading order. It handles tables, equations, and handwriting across complex multi-column layouts. The model is trained with reinforcement learning from verifiable rewards, using synthetic unit tests as the reward signal. olmOCR 2 scores 82.4 on its own olmOCR-Bench, among the higher published results on

LlamaIndex has published legal-kb, a public reference application on GitHub. It is described as a knowledge base for legal documents, powered by LlamaIndex Index v2 (the LlamaParse Platform). The project demonstrates a pattern the team calls a Retrieval Harness for agentic retrieval. The approach differs from single-shot retrieval. Instead of one embedding search per query, an agent is given filesystem-style tools. It can then crawl a large, evolving knowledge base to solve a task. The tools mirror operations engineers already know: semantic and keyword search, regex grep, file search, and read. What is legal-kb? legal-kb is a working TanStack Start web app, not a library. You sign in, create a project, upload files, and chat with an agent. Each project is mirrored as a managed LlamaCloud Index v2. Uploaded files are parsed and indexed automatically in the background. The chat agent then queries that index live during each turn. The Retrieval Harness, in plain terms The harness provides a persistent data pipeline over your documents. It connects to a data source, indexes it, and keeps it updated. On top of that pipeline, it exposes a set of tools to the agent. Those tools are deliberately close to filesystem operations. An agent can list files, read a file, grep inside a file, or run hybrid search. Because the tools are generic, you can plug the harness into your own agents. The four agent tools The agent in src/lib/agent.ts is given four tools. Each maps to an Index v2 retrieval API. The table below lists them as implemented. Tool Backing API Key parameters What it does retrieve beta.retrieval.retrieve query, top_k, score_threshold, rerank_top_n, file_name, file_version Runs hybrid semantic search; optional reranking; returns chunks plus citations findFiles beta.retrieval.find file_name, file_name_contains Searches files by exact name or substring; paginates automatically readFile beta.retrieval.read file_id, offset, max_length Reads raw file content, with offset and length windows grepFile beta.retrieval.grep file_id, pattern, context_chars, limit Matches a pattern in one file; returns character positions The system prompt enforces an order. The agent must call findFiles first to establish the document inventory. It then narrows with retrieve, and confirms exact wording with readFile or grepFile before citing. How it works under the hood Uploads follow a clear pipeline in src/lib/files.ts. Bytes are pushed to the project’s LlamaCloud source directory. A File and ProjectFile row are written to PostgreSQL via Prisma. An index sync is triggered but not awaited; the UI polls status until ready. Versioning is scoped to the (project, filename) pair. Re-uploading nda.pdf to the same project produces v1, v2, v3 side by side. The retrieval layer filters on the version metadata field. This gives version control over the knowledge base itself. The agent uses the ToolLoopAgent from Vercel AI SDK 6. You pick OpenAI or Anthropic per turn and bring your own keys. Reasoning is streamed: Claude models use extended thinking; OpenAI reasoning models use a medium reasoning effort. Here is a condensed but faithful view of the retrieve tool and the agent. Copy CodeCopiedUse a different Browser import { LlamaCloud } from ‘@llamaindex/llama-cloud’ import { tool, ToolLoopAgent } from ‘ai’ import { z } from ‘zod’ import { makeCitationId } from ‘./citations’ // One tool closure per index. Wraps Index v2 retrieval APIs. function createLlamaParseTools(apiKey: string, projectId: string, indexId: string) { const client = new LlamaCloud({ apiKey }) const retrieve = tool({ description: ‘Run a semantic retrieval query against an index.’, inputSchema: z.object({ query: z.string(), top_k: z.number().nullable(), score_threshold: z.number().nullable(), rerank_top_n: z.number().nullable(), // set to enable reranking file_name: z.string().nullable(), // metadata filter file_version: z.number().nullable(), }), execute: async ({ query, top_k, score_threshold, rerank_top_n, file_name }) => { const custom_filters = file_name ? { file_name: { operator: ‘eq’ as const, value: file_name } } : undefined const response = await client.beta.retrieval.retrieve({ index_id: indexId, project_id: projectId, query, top_k, score_threshold, rerank: rerank_top_n != null ? { enabled: true, top_n: rerank_top_n } : undefined, custom_filters, }) // Return a model-readable list plus citations that drive the UI chips. const citations = response.results.map((r) => ({ id: makeCitationId(), // e.g. “c7f2qa” fileName: r.metadata?.file_name, score: r.rerank_score ?? r.score ?? null, preview: r.content.slice(0, 500), })) const formatted = response.results .map((r, i) => `### Result #${i + 1}nn${r.content.slice(0, 600)}`) .join(‘nn—nn’) return { formatted, citations } }, }) // findFiles / readFile / grepFile follow the same shape, backed by // client.beta.retrieval.find / .read / .grep return { retrieve /* , findFiles, readFile, grepFile */ } } export function buildAgent(model, apiKey: string, projectId: string, indexId: string) { return new ToolLoopAgent({ model, tools: createLlamaParseTools(apiKey, projectId, indexId), instructions: ‘Always call findFiles first, ground every answer in the documents, ‘ + ‘and cite ids inline as `cite:<id>`.’, }) } Answers carry visual citations. Each retrieved chunk gets a short id, such as cite:c7f2qa. The agent references that id inline, and the UI renders a clickable citation chip. Clicking it opens the source page screenshot with bounding-box rectangles over the cited text. Naive RAG vs the agentic Retrieval Harness The harness is a different execution model from single-shot RAG. The comparison below focuses on behavior. Dimension Naive / single-shot RAG Agentic Retrieval Harness (Index v2) Retrieval flow One vector search per query Multi-step tool loop: find → retrieve → read/grep Search modes Vector similarity only Hybrid semantic search, keyword, and regex grep Context Fixed top-k chunks Agent reads full files or windows on demand Freshness Static index Persistent pipeline with sync and versioning Precision control Mostly hidden top_k, score_threshold, rerank_top_n exposed Citations Chunk ids Visual citations with page screenshots and bboxes Best fit Short question answering Long-horizon document tasks Use cases, with examples The design targets domains where agents navigate large document sets. Legal and fintech are the stated examples. Consider a contract question: ‘What notice is needed to terminate the MSA?’ The agent lists files, runs retrieve, then greps the exact clause. It answers with a citation to the specific page. Consider due diligence across a data room: An agent can findFiles by name, then readFile each candidate. It cross-checks clauses without a human opening every PDF. Consider a versioned policy base: