# Chain-of-Density: Maximum Information Density [Skip to content](#lm-inhoud)Network/NL[EN](/en/)[Hubhub.llmnet.nlCompare models by task, language, cost and license.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs robust in software: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlIntroducing AI in an organization, from pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlDevelopments in AI, interpreted for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, for your own tasks.](https://benchmark.llmnet.nl/en/)[Jobsvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, from beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for people who build their own.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fchain-of-density-steeds-informatievere-samenvattingen&text=Chain-of-Density%3A%20Maximale%20Informatiedichtheid)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fchain-of-density-steeds-informatievere-samenvattingen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fchain-of-density-steeds-informatievere-samenvattingen&title=Chain-of-Density%3A%20Maximale%20Informatiedichtheid)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fchain-of-density-steeds-informatievere-samenvattingen&text=Chain-of-Density%3A%20Maximale%20Informatiedichtheid)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fchain-of-density-steeds-informatievere-samenvattingen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fcommunity.llmnet.nl%2Fchain-of-density-steeds-informatievere-samenvattingen&title=Chain-of-Density%3A%20Maximale%20Informatiedichtheid)[](#) # Chain-of-Density: Ever More Informative Summaries By Ivo Donker — compiled with AI assistance (Claude & Gemini) · 21 August 2026 Summarizing is one of the most frequently performed tasks for large language models in production environments. Yet standard instructions such as "summarize this text in 100 words" surprisingly often produce disappointing results. In such a scenario, models fall back on a recognizable pattern: they select the most obvious central storyline and fill the remaining space with wordy transitional sentences, function words and vague container terms. The end result does read fluently and is grammatically flawless, but the information density per sentence stays remarkably low. A professional therefore loses valuable time working through text that contains few hard facts. The Chain-of-Density (CoD) technique breaks through this limitation by raising the information density of a summary step by step and purposefully within a strictly maintained length limit. Instead of a one-off, static generation, the algorithm forces the model to identify missing entities from the source text in a successive cycle and to weave them in through active syntactic reformulation. In this article we dissect the mathematical and linguistic workings of Chain-of-Density, compare concrete implementation templates and present measurement methods to quantify entity density objectively. To determine when this intensive technique pays off compared with other prompting strategies, consult the overview of [which prompt technique to use when](https://community.llmnet.nl/en/prompttechniek-kiezen). ## The fundamental problem with standard summaries When a language model is asked to summarize a complex source document without further structural steering, the probabilistic generation process optimizes primarily for general syntactic coherence and global context representation. This leads to a pronounced preference for grammatical filler: subordinate clauses beginning with "it is important to note that", passive constructions and repetitive paraphrases. The model takes the statistically safest route to fill up the requested number of words without taking any factual risks. In professional domains such as financial audits, legal document analysis, technical incident reports or clinical records, this traditional form of summarizing is downright ineffective. An investment analyst or engineer has no use for generalities such as "the board has implemented operational changes to strengthen its market position". There is a direct need for the exact parameters: which production sites have been closed, which patents have been acquired, which drop in revenue in percent has been recorded and which key figures have been replaced. Anyone who wants to grasp the underlying basic principles of length control and source fidelity can turn to the guide on [summarization prompts that hold up](https://community.llmnet.nl/en/prompts-voor-samenvatten). Simply instructing a model to include "as many facts and entities as possible" in a single-shot prompt fails every time. Under such uncontrolled pressure two extremes arise: the model loses its grammatical integrity and produces an incoherent list of loose keywords, or it ignores the given length restriction entirely and still generates a long-winded document. Chain-of-Density offers a controlled, mathematical and linguistic framework to perfect this interplay between information load, length limit and grammatical coherence step by step. ## What is Chain-of-Density (CoD)? Chain-of-Density is a specialized prompt engineering method in which a language model produces a series of successive summaries, traditionally built up out of five iterative steps. The process deliberately starts with an initial summary that is intentionally "airy" and verbose in design. This first version covers the broad outlines of the source document, but contains relatively few specific nouns, figures or unique names. From iteration two onwards, the model carries out two closely intertwined actions on every pass: - Entity identification: The model scans the source text and selects one to three specific, informative entities (Missing Entities) that are crucial for understanding the topic but do not yet appear in the preceding summary. For anyone who wants to set up entity recognition as a separate task, the patterns for [data extraction from unstructured text](https://community.llmnet.nl/en/prompts-voor-data-extractie) are worth consulting. - Compressive integration: The model rewrites the previous summary completely. The new entities are inserted, while the total number of words has to stay strictly within the original limit. Because the total number of words stays constant throughout all steps, the prompt forces the model into aggressive stylistic reduction. Fixed expressions, empty signal words and passive constructions have to give way to compact appositions, compound nouns and direct action verbs. The process stops when maximum entity saturation is reached. This results in a series of texts with a steadily rising information density. This approach differs fundamentally from techniques that are purely aimed at reducing token volumes for machine input. While with [prompt compression for long contexts](https://community.llmnet.nl/en/prompt-compressie-voor-lange-contexten-samenvatten-of-inkorten) the filtering is often pragmatically based on relevance in order to lower downstream API costs, Chain-of-Density optimizes primarily for human information processing: maximizing the factual transfer per second of reading time. ## The step-by-step CoD algorithm dissected To grasp the mechanics of this transformation, we analyze the five typical steps of the Chain-of-Density process. In doing so we use the strict definition of a Missing Entity: a specific fact, quantitative value, personal name, geographical designation, organization or causal event that comes directly from the source document but was missing from the immediately preceding summary. Iteration | Primary objective | Entity density (estimate) | Typical linguistic characteristics | Step 1: initial | Sketch general context and main storyline | Low (~0.08 entities/word) | Many function words, compound subordinate clauses, passive verb forms. | Step 2: first enrichment | Insert 1-3 primary key entities | Moderate (~0.13 entities/word) | Removal of superfluous run-ups; replacement of pronouns by names. | Step 3: balance point | Further detailing and causal links | Optimal (~0.17 entities/word) | Use of compact appositions and directly linked action verbs. | Step 4: high compression | Weave in secondary parameters and figures | Very high (~0.21 entities/word) | Contraction of main clauses; maximum reduction of connecting words. | Step 5: saturation | Maximum entity intake within the word limit | Extreme (~0.25 entities/word) | Almost telegram style; abstract sentence structure; risk of losing readability. | The decisive mechanism behind the success of this algorithm is the explicit separation between identification and integration. Because the prompt prescribes that the model must first generate the list of Missing_Entities as an intermediate step before the new summary is written, this list acts as an external working memory. In doing so the model activates the relevant attention vectors in the neural network, which drastically reduces hallucinations during the subsequent compression pass. ## An illustrative example: 5 iterations of a fictional IT incident To demonstrate the transformation in practice, we look at an illustrative, invented example about an IT emergency. The fictional case describes a network failure at the invented institution Ziekenhuis De Noorderbrug, caused by a faulty firmware update from the hypothetical supplier MedTech Systems, as a result of which 28 planned treatments had to be rescheduled and local emergency power supplies were brought in. ### Iteration 1 (airy, not very specific — 54 words) "A significant technical failure recently occurred at a regional hospital, seriously disrupting regular operations. Various medical procedures had to be cancelled as a precaution to safeguard patient safety. The organization immediately took measures to restore the systems and is currently investigating the exact cause of the incident." Identified entities: regional hospital (1 entity in 54 words = density 0.02). ### Iteration 2 (adding Ziekenhuis De Noorderbrug, firmware update, server outage — 55 words) "A failed firmware update caused an acute server outage at Ziekenhuis De Noorderbrug, temporarily paralyzing regular care provision. Several planned medical procedures had to be cancelled immediately to avoid risks to patients. The IT team switched straight to emergency protocols to restore the vital databases safely and to analyze the root cause thoroughly." New entities: firmware update, server outage, Ziekenhuis De Noorderbrug (4 entities in 55 words = density 0.07). ### Iteration 3 (adding MedTech Systems, 28 planned treatments — 53 words) "A defective firmware update from supplier MedTech Systems brought down the central database of Ziekenhuis De Noorderbrug. As a result, doctors had to postpone 28 planned treatments and switch to emergency procedures. Technical teams immediately activated recovery protocols to safeguard patient safety and to check the integrity of medical records manually." New entities: MedTech Systems, central database, 28 planned treatments (7 entities in 53 words = density 0.13). ### Iteration 4 (adding emergency power supplies, data integrity check — 52 words) "MedTech Systems' defective firmware update crashed the Noorderbrug database, leading to the postponement of 28 treatments and the activation of emergency power supplies. Specialists manually checked the data integrity of patient records while emergency protocols were running. Within four hours, technicians restored the servers without lasting data loss for the clinical departments." New entities: emergency power supplies, data integrity of patient records, four hours (10 entities in 52 words = density 0.19). ### Iteration 5 (maximum saturation — 51 words) "MedTech Systems' defective firmware update crashed Noorderbrug's central database: 28 treatments postponed, emergency power supplies switched on and records manually validated for data integrity. Clinical teams maintained emergency protocols while IT specialists restored full server functionality within four hours without patient record damage or structural data loss." New entities: manual validation, full server functionality, structural data loss (13 entities in 51 words = density 0.25). In this example it is clearly visible how iterations 3 and 4 keep an excellent balance between rich context and easy readability, while iteration 5 is very compact and demands greater cognitive effort from the reader. ## Measurement methods for information density in text To evaluate Chain-of-Density objectively in automated pipelines, a subjective judgment is not enough. Formal metrics are needed to establish whether a model actually adds entities without breaching the length limit. In practice three complementary measurement methods are used: - Direct entity density (Entity Density Metric): This is the ratio between the number of unique extracted entities and the total number of words in the summary: Dichtheid = (Aantal Unieke Entiteiten) / (Totaal Aantal Woorden) This uses a Named Entity Recognition (NER) pipeline (such as spaCy or a specialized extraction model) to count personal names, organizations, locations, dates and numerical values. A healthy CoD series shows a steady rise from around 0.08 in iteration 1 to over 0.22 in iteration 5. - Token-to-Fact Ratio (TFR): This metric calculates how many separate factual claims (propositions) a text fragment contains per 100 generated tokens. This is often done via an LLM-as-a-Judge setup that breaks the text down into atomic facts and checks whether these facts can be traced directly back to the source text. - Readability index (Flesch-Kincaid & Gunning Fog): As entity density increases, the traditional readability score inevitably drops because sentences become more complex and the percentage of multisyllabic words rises. Monitoring this score prevents a model from overshooting into incomprehensible telegram style. ## A robust Chain-of-Density prompt in practice For stable operation in production via API integrations, a strict instruction structure is indispensable. Without explicit schema definitions, language models tend to exceed the word limit after the second iteration or to invent entities. To prevent the model from stepping outside the JSON format, the guide on [enforcing form from the prompt itself](https://community.llmnet.nl/en/structured-output-in-prompts-afdwingen) is essential for a reliably parsable structure. You will generate increasingly concise, entity-dense summaries of the provided article. Guidelines: - Carefully read the source text and identify core information and specific entities. - You will perform exactly 5 sequential iterations of summarization. - Each summary must be EXACTLY between 50 and 65 words long. - Summary 1 must be informative but verbose, containing few specific entities (broad overview). - For Summaries 2 through 5: 1. Identify 1 to 3 Missing Entities from the article that are NOT present in the previous summary. 2. Rewrite the previous summary to seamlessly integrate these new entities. 3. Keep the total word count strictly within the 50-65 word limit. 4. Make space by fusing sentences, removing conversational filler, and using dense phrasing. 5. Never invent facts; every entity must be grounded in the source text. Output strictly valid JSON matching this schema: [ { "iteration": 1, "missing_entities": [], "word_count": 58, "summary": "..." }, { "iteration": 2, "missing_entities": ["Entity A", "Entity B"], "word_count": 61, "summary": "..." }, { "iteration": 3, "missing_entities": ["Entity C", "Entity D"], "word_count": 59, "summary": "..." }, { "iteration": 4, "missing_entities": ["Entity E"], "word_count": 62, "summary": "..." }, { "iteration": 5, "missing_entities": ["Entity F", "Entity G"], "word_count": 60, "summary": "..." } ] Article text: {{ARTICLE_TEXT}} When rolling out such prompts across various model architectures, it is wise to evaluate systematically which model delivers the best compression without introducing hallucinations. For setting up reliable evaluation studies, the methodology for [A/B testing of prompts](https://benchmark.llmnet.nl/en/ab-testen-prompts) offers the necessary handles to compare variants quantitatively. ## Entity density versus human readability: the trade-off A higher information density is not desirable under all circumstances. Extensive human evaluations consistently show that readers have a strong preference for summaries from iteration 3 or iteration 4. Iterations 1 and 2 are judged too vague and inefficient, while many experience iteration 5 as tiring and stylistically stiff. When entity density rises above the threshold of around 0.22 entities per word, specific cognitive and linguistic frictions arise: - Disappearance of causal links: To save space, the model removes connecting words such as "because", "as a result of which" and "conclusion". As a result the text changes from a coherent argument into a string of loose factual observations, which forces the reader to construct causal links themselves. - Syntactic overload: Frequently stacking adjectival modifiers and compound nouns creates sentences with an extremely high information pressure. The reader has to reread sentences several times to work out which modifier belongs to which head word. - Increased cognitive load: Although the physical text is short, the processing time per word increases considerably. For fast scanning by people, a moderate density (step 3) is therefore more productive than maximum compression (step 5). For automated processing chains the opposite applies: search engines, semantic vector databases and automated knowledge systems function best at iteration 5, because this version contains the maximum amount of searchable keywords and relations within a minimal number of tokens. ## Pitfalls, model drift and hallucinations with CoD Forcing a language model to compress brings considerable risks with it. Because the model is under heavy pressure both to include new entities and to guard the length, specific error patterns occur more frequently than with standard generative tasks. The most treacherous phenomenon is Entity Fusion Hallucination (entity fusion). When a model tries to merge two separate sentences into one compact sentence, there is a danger that properties of one object are accidentally attributed to the other. If the source text states that "System X showed a memory leak" and "Server Y overheated due to cooling problems", an over-compressed step 4 summary can wrongly report that "System X overheated due to a memory leak". These errors are hard for human readers to spot because the names and terms do actually occur in the source text. A second risk is length drift. Compact and locally running models in particular often lose control of the word limit around iteration 3. They add the new entities neatly, but do not manage to cut away enough existing text. The result is cumulative growth of the text length, which undoes the basic principle of Chain-of-Density. This requires automated validation layers on the API output. ## Cost, latency and optimization in production The biggest practical drawback of Chain-of-Density in production environments concerns the operational costs and the processing time. Because the model has to generate five complete summaries sequentially in a single call, the task consumes considerably more output tokens than a standard summary. On top of that, generating five iterations can take several seconds, which is undesirable for interactive user interfaces. A detailed analysis of the financial impact of this increased token volume can be found in the article on [what a prompt costs in tokens, caching and the bill](https://community.llmnet.nl/en/wat-een-prompt-kost-tokens-caching-en-de-rekening). Architecture variant | Token usage (relative) | Latency profile | Recommended application area | Full 5-step CoD (monolithic) | High (100% baseline) | High (fully sequential) | Asynchronous batch processing of analysis reports. | Early stop (3 iterations) | Medium (~55% saving) | Medium | Direct presentation to human end users. | Two-step extraction and compression | Low to medium | Low (parallelizable) | Real-time dashboards and automated feeds. | To resolve these bottlenecks, organizations can make targeted architecture choices. By stopping at iteration 3 by default, you save more than half on token costs, while the generated text matches human preference exactly. For large-scale systems a two-stage architecture can be set up: a small, fast model first extracts all the core entities, after which a larger model generates a summary with a preset target density in one targeted step. ## Conclusion and implementation guidelines Chain-of-Density transforms text summarization from a passive writing assignment into a controlled, measurable compression process. By explicitly forcing language models to identify and weave in missing entities within a fixed word limit, the maximum return is extracted from every generated sentence. When setting up production pipelines around CoD, three central guidelines apply: match the number of iterations to the end user (step 3 for human consumption, step 5 for vector databases), implement strict validation against entity fusion, and opt for early stopping to keep token costs and latency under control. That makes Chain-of-Density an indispensable precision instrument in the arsenal of the modern prompt engineer.