---
title: 'DOC: Hierarchical Document Structure Analysis'
url: https://www.emergentmind.com/topics/detect-order-construct-doc
type: topic
---

# DOC: Hierarchical Document Structure Analysis

Searching arXiv for the cited DOC-related document parsing papers and closely related work.
arXiv search query: "Detect-Order-Construct hierarchical document structure analysis RT-DocLayout parser-oriented structural refinement"
Detect-Order-Construct (DOC) is a unified, tree-construction–based framework for Hierarchical Document Structure Analysis (HDSA). In its original formulation, DOC treats document understanding as a single pipeline that begins with page object detection, proceeds through reading-order prediction, and ends with reconstruction of a hierarchical document tree that captures both physical layout and logical structure, such as section hierarchy and caption attachment [2401.11874].

## 1. Conceptual framework and problem setting

DOC decomposes document analysis into three coupled stages: **Detect**, which identifies page objects and assigns logical roles; **Order**, which predicts reading order and inter-object relations; and **Construct**, which builds the abstract hierarchical tree. The final document is modeled as a rooted tree whose nodes are page objects and whose edges encode text-region reading order relationships, graphical-region relationships, and Table of Contents (TOC) relationships. Reading order is interpreted as a pre-order traversal of that tree [2401.11874].

The framework is motivated by the limitations of treating page object detection, reading order prediction, and hierarchy extraction as isolated subtasks. In the formulation associated with DOC, errors compound when these stages are separated, whereas a tree-construction view allows the system to represent page objects as tree nodes and structural relations as edges in a common representation. This suggests that DOC is not merely a pipeline decomposition but a structural hypothesis about how rendered documents should be modeled.

DOC is explicitly targeted at documents authored with hierarchical schemas, such as LaTeX, Microsoft Word, and HTML. The intended output is therefore more than a flat ordered list of regions: it is a hierarchical reconstruction that can support information retrieval, document summarization, knowledge extraction, and accessibility-oriented reflow [2401.11874].

## 2. Detect: page-object formation and logical role assignment

In DOC, the Detect stage must recover both **graphical page objects** and **text regions**. Graphical objects such as tables, figures, and formulas are obtained with a top-down detector built on a shared visual backbone. Text regions are produced bottom-up by starting from text lines extracted from PDF or OCR, filtering out lines inside graphical objects, and then grouping the remaining lines into higher-level regions such as paragraphs, titles, section headings, footnotes, captions, and list items [2401.11874].

For each text line \(t_i\), the system forms a multi-modal representation from visual, textual, and 2D positional features. The visual embedding is obtained from fused backbone features and RoIAlign; the textual embedding is derived from BERT\(_{\text{BASE}}\); and the positional embedding encodes normalized box coordinates and size. These are concatenated and projected to form the line representation \(U_{t_i}\), which is then refined by a Transformer encoder:
$$
F_t = \text{TransformerEncoder}(U_t) = [F_{t_1}, \dots, F_{t_n}].
$$

The key operational step in bottom-up detection is **intra-region reading-order relation prediction**. Instead of binary link prediction, DOC casts successor selection as a dependency-parsing problem over candidate lines. For line pair \((t_i,t_j)\), the score is
$$
f_{ij} = FC_q(F_{t_i}) \circ FC_k(F_{t_j}) + \text{MLP}(r_{b_{t_i}, b_{t_j}}),
$$
followed by
$$
s_{ij} = \frac{\exp(f_{ij})}{\sum_{j'} \exp(f_{ij'})}.
$$
The predicted line-to-line chains are merged by Union-Find into text regions, and logical roles are assigned by line-level classification followed by region-level voting [2401.11874].

A central empirical claim of the framework is that this hybrid strategy materially improves page object detection. On DocLayNet, DOC improves over the best baseline by **4.2 mAP points** (76.8 to 81.0), and on Comp-HRDoc, the hybrid vision-plus-text Detect module reaches **88.06** segmentation mAP versus **73.54** for Mask2Former-R50 [2401.11874].

## 3. Order: reading order as structured relation prediction

The Order stage operates on the page objects produced by Detect: text regions and graphical page objects. Its purpose is twofold: to recover a **reading-order chain** and to classify **inter-region relation types**, distinguishing ordinary text-region order from graphical relations such as caption–figure or footnote–table links [2401.11874].

Text-region representations are obtained by attention-based pooling over their constituent line features, while graphical objects are encoded from visual features and geometry. A region-type embedding representing the logical role is concatenated with the pooled feature, and all page-object embeddings are then processed by a Transformer encoder:
$$
F_O = \text{TransformerEncoder}(\hat{U}_O) = [F_{O_1}, \dots, F_{O_n}].
$$
Successor prediction between page objects reuses the dependency-style scoring pattern already used at line level, again with softmax over candidate successors rather than independent binary decisions [2401.11874].

Within the broader DOC literature represented here, later work makes the order component even more explicit as a relational module over detected elements. RT-DocLayout models reading order by first assigning each element an absolute order index \(o_i\), constructing a pairwise precedence target
$$
T_{i,j} =
\begin{cases}
1 & \text{if } o_i < o_j \\
0 & \text{otherwise},
\end{cases}
$$
and predicting an antisymmetric pairwise score matrix
$$
S_{i,j} = \frac{(W_q q_i)^\top (W_k q_j) - (W_q q_j)^\top (W_k q_i)}{\sqrt{d_h}}.
$$
Inference converts pairwise scores into a global sequence by computing
$$
V_j = \sum_{i=1}^N \sigma(S_{i,j}),
$$
then sorting elements in ascending order of \(V_j\). The paper characterizes this design as “almost a textbook example of a Detect–Order–Construct (DOC) system,” but implemented in a single unified Transformer [2606.23344].

A related parser-interface stabilization method formalizes the same stage differently. It inserts a structural refinement block between a DETR-style detector and a parser, treating the raw outputs as a hypothesis pool and jointly predicting refined boxes, retention probabilities, and an ordering score \(\hat{o}_i\). Pairwise precedence is modeled by
$$
P(i \prec j) = \sigma(\hat{o}_j - \hat{o}_i),
$$
with a difficulty-aware weight
$$
w_{ij} = 1 + \gamma \log(1 + n_{ij}^{\mathrm{mid}}),
$$
so that structurally ambiguous pairs receive more emphasis during training [2604.02692].

## 4. Construct: hierarchical tree assembly and parser-facing structure

The Construct stage uses the ordered objects to build a hierarchical tree, with particular emphasis on section headings and TOC extraction. In DOC, the section headings \([sec_1,\dots,sec_k]\) are first arranged in reading order and then encoded with a Transformer using RoPE:
$$
F_S = \text{TransformerEncoder}_{\text{RoPE}}(U_S) = [F_{S_1}, \dots, F_{S_k}].
$$
Two dependency-style heads are then applied: one predicts **parent–child** relations, and the other predicts **left-sibling** relations. For the parent head,
$$
s^p_{ij} = \frac{\exp(f_{ij})}{\sum_j \exp(f_{ij})},
$$
and an analogous score \(s^s_{ij}\) is used for siblings [2401.11874].

Inference does not simply accept pairwise predictions independently. Instead, DOC uses a **serial tree insertion algorithm**. For a new heading \(sec_i\), candidate parents are drawn from the rightmost subtree frontier, parent scores and sibling scores are multiplied elementwise,
$$
\mathbf{scores} = \mathbf{scores_p} \circ \mathbf{scores_s},
$$
and \(sec_i\) is inserted as the right-most child of the maximizer. This enforces a valid rooted ordered tree and operationalizes the claim that parent and sibling information must be decoded jointly [2401.11874].

The Construct stage extends beyond TOC extraction in later DOC-style systems. RT-DocLayout defines the “Construct” phase as taking per-element class labels, bounding boxes, masks, and predicted order, then using masks or boxes to crop regions, route them to text OCR, formula recognition, or table structure recognition, and finally sequence the recognized outputs into HTML, Markdown, LaTeX, or PDF-like structure [2606.23344]. The parser-oriented refinement paper makes the same stage explicit as a detector-to-parser handoff: retained instances are sorted by predicted order and passed as a stabilized parser interface to downstream systems such as PaddleOCR-VL‑1.5 or GLM‑OCR [2604.02692].

This suggests that, across document parsing variants, the Construct stage increasingly denotes not only hierarchy induction but also the preparation of a parser-consumable structured interface.

## 5. Benchmarks, metrics, and empirical behavior

The original DOC work introduces **Comp-HRDoc**, built on HRDoc-Hard, with **1,000 documents for training** and **500 for testing**. It evaluates four tasks jointly: page object detection, reading order prediction, TOC extraction, and hierarchical structure reconstruction. Page object detection is evaluated with segmentation-based mAP. Reading order is evaluated with **Reading Edit Distance Score (REDS)**, defined after Hungarian matching of predicted and ground-truth reading-order groups as
$$
\text{REDS} = 1 - \frac{D}{N},
$$
where \(D\) is total Levenshtein edit distance and \(N\) is the total number of units, including the special `</p>` token inserted to reflect paragraph boundaries [2401.11874].

On Comp-HRDoc, DOC reports **88.06** segmentation mAP for page object detection, **0.9319** Text Region REDS, **0.8637** Graphical Region REDS, **0.8605** Micro-STEDS and **0.8788** Macro-STEDS for TOC extraction, and **0.8371** Micro-STEDS and **0.8365** Macro-STEDS for full hierarchical reconstruction. On HRDoc-Hard, DOC reaches **0.8566** Micro-STEDS and **0.8548** Macro-STEDS for hierarchical reconstruction, substantially above DSPS Encoder, which uses true reading order as input [2401.11874].

Ablation results in the original framework show that the hybrid detect strategy and multimodal features are central. On Comp-HRDoc, Hybrid-R18 with vision only reaches **83.40** segmentation mAP, and Hybrid-R18 with vision plus text reaches **88.06**. In the TOC module, removing the sibling-finding head reduces Micro-STEDS from **0.8605** to **0.8545**, removing the Tree Insert Algorithm reduces it to **0.7111**, and replacing softmax multi-class prediction with binary cross-entropy reduces it to **0.7002** [2401.11874].

Later DOC-style systems emphasize speed and robustness under real-world distortions. RT-DocLayout uses a **33M-parameter** architecture, runs at **132.1 FPS** on A100 with batch 32, and unifies classification, detection, segmentation, and reading-order prediction in a single model. With PaddleOCR-VL‑1.5-0.9B on OmniDocBench v1.5 it reports **Overall = 94.50**, and on Real5-OmniDocBench it reports **Overall = 92.05**, with **Warp = 91.25** and **Skew = 91.66**. Its ablation shows a decoupled reading-order module reaches **RO = 0.189** on OmniDocBench, whereas coupling order prediction inside the decoder yields **RO = 0.041** [2606.23344].

Parser-oriented structural refinement focuses on stability of the retained instance set and parser input order. It reports **Reading Order Edit of 0.024 on OmniDocBench** and **0.036 on Real5-OmniDocBench**. Ablation indicates that removing retention-oriented supervision drops Overall from **94.63** to **90.84**, while removing difficulty-aware ordering leaves F1 and Overall unchanged but worsens Reading Order Edit from **0.024** to **0.061** [2604.02692].

## 6. Subsequent interpretations, variants, and acronym disambiguation

Within document parsing, DOC has been used both as the title of a specific tree-construction framework and as a conceptual lens for later systems. RT-DocLayout explicitly describes itself as nearly a textbook DOC system, but collapses Detect, Order, and Construct into a single forward pass with shared query embeddings [2606.23344]. Parser-oriented structural refinement does not use DOC as its formal name, but its own stage mapping is detector \(\rightarrow\) layout instances \(\rightarrow\) parser, and it explicitly identifies a middle structural module that decides retention, localization, and order jointly before construction by the downstream parser [2604.02692]. A plausible implication is that DOC has evolved from a tree-reconstruction framework into a more general description of structured document parsing pipelines.

The acronym “DOC,” however, is not unique to document structure analysis. In the arXiv literature covered here, it also designates unrelated methods in vision, security, and language generation.

| Expansion of DOC | Domain | Paper |
|---|---|---|
| Deep OCclusion | Single-image occlusion estimation | [1511.06457] |
| Deep One-Class | Network anomaly detection | [2212.07558] |
| Detailed Outline Control | Long-story generation | [2212.10077] |

“DOC: Deep OCclusion” defines DOC as a two-stream fully convolutional architecture for boundary detection and border ownership estimation, where each boundary pixel has label pair \(l=\{e,\theta\}\) and \(\theta\) encodes foreground/background assignment by a left rule [1511.06457]. “DOC-NAD” defines DOC as a hybrid DeepSVDD-plus-HBOS one-class classifier for network intrusion detection trained only on benign flows [2212.07558]. “DOC: Improving Long Story Coherence With Detailed Outline Control” defines DOC as a planning-and-control framework for long-form story generation built from a detailed outliner and a detailed controller [2212.10077].

For the document-analysis meaning of Detect-Order-Construct, the principal open directions stated in the source literature are broader document types, stronger handling of documents without section numbers or stable typographic cues, page-spanning or multi-page ordering, and extension from strictly tree-structured outputs to more general graph structures [2401.11874]. Subsequent work also points to multi-page order, hierarchical relations beyond block level, and ambiguity in non-linear reading orders as unresolved design problems for DOC-style systems [2606.23344].

Source: https://www.emergentmind.com/topics/detect-order-construct-doc