PaperlayerView exact revision on arXiv

Source-linked AI summary

DConstrain: Compiling Context-Parameterized Transitions for Diffusion Language Model Constrained Decoding

Shidong Cao, Jing Ma, Wenhao Chai, Yuchen Tian, Lun Du, Da Zheng

arXiv:2610.30920v1cs.AI

TL;DR

DLMs decode multiple tokens in parallel, so individually valid tokens can conflict under a schema, and exact joint inference needs successors across many hypothetical parser configurations. DConstrain compiles reusable context-parameterized programs and token groups; across structured-output benchmarks it improves compilation coverage and latency, with 100% strict-schema validity on BFCL cases.

  • Problem

    Parallel DLM decoding can combine individually valid tokens that are incompatible under a schema, while exact joint inference requires successors across many hypothetical configurations and finite-state encodings can grow exponentially.

    Source: §1 · p. 2

  • Method

    DConstrain compiles context-parameterized transition programs that retain runtime context symbolically and groups tokens by compiled effects for reuse across contexts.

    Source: §1 · p. 2

  • Results

    Across three structured-output benchmarks and multiple DLM tokenizers, DConstrain improves compilation coverage and latency under arbitrary property order, completing BFCL cases with 100% strict-schema validity.

    Source: §1 · p. 3, §5.1 · p. 10

  • Takeaways & Limitations

    The compiled programs can be reused by constrained-decoding algorithms that consume token-labeled grammar successors, while grouping preserves exact inference outcomes.

    Source: §1 · p. 3

Abstract

from arXiv · show

Diffusion language models (DLMs) decode multiple tokens in parallel, so individually valid tokens can be incompatible together under a schema. Exact joint inference over a grammar graph enforces compatibility, but it requires token-labeled successors across many hypothetical parser configurations. Encoding stacks and field histories in compiled states can cause exponential growth, which forces prior exact decoders to fix property orders and exclude valid outputs. We present DConstrain, which compiles schemas into context-parameterized transition programs. Cold compilation specializes token consumption to local grammar states while retaining context-dependent stack operations, environment guards, and caller-dependent deferred parsing symbolically. Tracking field histories as runtime values supports arbitrary property order without enumerating field subsets offline. At runtime, warm compilation binds reached configurations to these programs to construct exact successors, overlapping with the model forward pass because graph construction requires no model scores. Furthermore, token-effect grouping merges tokens with identical compiled effects before runtime contexts are bound, so groups are reused across stacks and environments even when concrete successors differ. Objective-specific score aggregation and token restoration provably preserve both the Viterbi optimum and the token-labeled path distribution of ungrouped inference. Across three benchmarks and two DLM families, DConstrain compiles 100% of BFCL schemas under arbitrary property orders, whereas an optimized finite-state baseline compiles only 71.30-85.81%. Under arbitrary property order, it reduces BFCL end-to-end decoding latency by 6.65-46.26 times with 100% schema validity and raises DiffusionGemma's BFCL accuracy from 37.27% under fixed order to 81.56%.

1 Introduction

DLMs generate multiple tokens in parallel, so individually valid tokens can conflict, while exact joint inference requires successor configurations across many hypothetical parser states. DConstrain compiles context-parameterized transition programs to support arbitrary property orders while improving compilation coverage and latency.

1 Introduction

  • DLM parallel decoding can combine individually valid tokens into outputs that violate schema rules.Unlike autoregressive decoding, which masks invalid next tokens for a realized prefix, parallel generation must account for interactions among tokens.Source: §1 · p. 2
  • Exact automata-based DLM decoders require compatible token paths, but constructing token-labeled successors across hypothetical configurations is costly.Verification-based decoders instead propose tokens independently, risking conflicts, repeated resampling, or heuristic fallbacks under finite budgets.Source: §1 · p. 2
  • Encoding nested stacks and unordered field histories in finite states can grow exponentially, leading prior exact decoders to fix property order and exclude valid outputs.DConstrain retains context-dependent stack operations and field histories symbolically, then constructs exact successors at runtime; its grouping preserves the Viterbi optimum and token-labeled path distribution.Source: §1 · pp. 2–3
  • Across three structured-output benchmarks and multiple DLM tokenizers, DConstrain improves compilation coverage and latency under arbitrary property order.On BFCL, exact unordered constraints also improve task accuracy over fixed-order constraints and unconstrained decoding.Source: §1 · p. 3

2 Related Work

Prior DLM constrained decoders use verification or automata-based joint inference; automata methods rely on finite-state transitions, while DConstrain compiles reusable context-parameterized programs for exact successors.

2 Related Work

  • Verification-based DLM decoders check independently sampled proposals and may resample or recover when grammar checks fail.Feasibility checks do not recover the highest-scoring joint assignment or an exact sample from the constrained distribution.Source: §2 · p. 3
  • Automata-based decoders coordinate token choices through joint inference over finite automata, with systems such as DINGO precomputing vocabulary-level transitions.Dang and Ermon (2026) group edges and sum their probabilities.Source: §2 · p. 3
  • Prior exact automata methods fix JSON property order to keep the automaton finite and small.Direct runtime pushdown parsing avoids context-specific states but repeatedly executes token-consumption logic for reached configurations.Source: §2 · p. 4
  • DConstrain compiles reusable local grammar–token programs and one token partition per local state for all runtime contexts.This extends edge-level token aggregation to parameterized transitions.Source: §2 · p. 4

3 Preliminaries

A schema parser configuration combines a local grammar state with a return stack and parsing environment, and DLM joint inference propagates exact token successors across a canvas. Finite-state representations can grow sharply with nesting and unordered field histories.

3 Preliminaries

  • A parser configuration c = (q, s, e) combines a local grammar state, a stack of pending return points, and an environment recording earlier choices such as written fields.A token-transition relation returns valid successor configurations after consuming a vocabulary token.Source: §3 · p. 4
  • Canvas grammar propagation advances reached configurations across candidate tokens to form a layered graph, which joint inference solves using max-product or sum-product.Propagation depends on parser configurations and candidate sets, not model scores.Source: §3 · p. 4
  • DLM joint inference needs exact successor sets for candidate tokens across many hypothetical configurations, rather than the boolean next-token mask used in autoregressive decoding.It must evaluate every candidate token at every reached configuration before committing any token.Source: §3 · pp. 4–5
  • Finite-state compilers duplicate shared grammar logic by materializing runtime contexts and precomputing transitions even for contexts a canvas may never reach.For bounded-depth brackets, context expansion grows with stack depth and the vocabulary transition table stores entries for each state–token pair.Source: §3 · p. 5
  • Unordered required properties create exponentially many field histories; for k fields, a factorized compiler uses O(k) local states and a k-bit runtime environment.The paper’s proposition gives exponential lower bounds for finite automata and context-free grammars representing such schemas.Source: §3 · p. 5
  • The representation-size bounds concern static automata and grammars, not the runtime cost of parsing one string.For offline finite-state compilers, representation size directly determines compilation cost.Source: §3 · p. 5

4 DConstrain

DConstrain separates local grammar logic from runtime context to construct exact successors for joint inference. Its cold and warm compilation stages are paired with token-effect grouping that shares work across contexts while preserving inference outcomes.

4 DConstrain

  • DConstrain compiles schemas into context-parameterized programs that implement the exact successor interface independently of the downstream decoding algorithm.Cold compilation specializes local grammar–token behavior; warm compilation executes programs for reached configurations, and token-effect grouping reuses partitions.Source: §4 · p. 6

4.1 Context-Parameterized Transition Compilation

  • Cold compilation specializes token consumption for each local state and token while leaving the stack, container depth, and choice environment unbound.Programs are ordered symbolic alternatives; residual programs defer caller-dependent parsing, while summaries encode statically determined targets and context operations.Source: §4.1 · p. 7
  • A single program set is shared across all written-field histories by keeping those histories as runtime bitmask values and applying guards for uniqueness and required-field completion.The program preserves the order and scope of environment guards and updates.Source: §4.1 · p. 7

4.2 Warm Compilation

  • Warm compilation binds compiled programs to reached configurations, resumes caller-dependent continuations, and returns the exact successors of the reference parser.Theorem 4.1 states that propagation reproduces the same layers, transitions, and token-labeled window language.Source: §4.2 · p. 8

4.3 Token-Effect Grouping

  • Compile-time token groups are shared across stacks and environments, and objective-specific aggregation with token restoration preserves the path distribution and Viterbi optimum.The same offline partition can serve different runtime contexts even when their concrete successor sets differ.Source: §4.3 · pp. 8–9
  • Warm compilation and grammar propagation overlap the model forward pass because neither requires model logits; joint inference starts when the graph and predictions are ready.Warm compilation runs on the first forward pass of each canvas, while later iterations reuse cached successors as candidate sets shrink.Source: §4.3 · p. 9

5 Experiments

Across three benchmarks and two DLM families, the experiments evaluate compilation coverage and cost, runtime validity and throughput, and the effects of arbitrary property order. DConstrain combines full arbitrary-order coverage on key benchmarks with faster decoding and high schema validity, while analyses examine its mechanisms and scaling.

5.1 Main Results

  • 100% compilation coverage on BFCL and ComplexFuncBench under arbitrary property order, with DConstrain 3.54–10.39× faster than DINGO-Opt on paired successful cases.DINGO-Opt compiles 71.30% of BFCL schemas with LLaDA2.2 and 85.81% with DiffusionGemma under Any-order.Source: §5.1 · p. 10, Table 1 · p. 11
  • 6.65× and 46.26× lower end-to-end latency than DINGO-Opt under Any-order, while DConstrain completes all 2,495 BFCL cases with 100% strict-schema validity in both models and order settings.DConstrain also has the highest TPS among constrained methods in all four common-cohort settings.Source: §5.1 · p. 10, Table 2 · p. 13

5.2 Ablation Study

  • Eagerly binding environment values during cold compilation raises mean compilation latency to 14.61× the full system, while removing token grouping raises mean solve latency to 6.81×.Local-state reuse avoids recompiling identical local transition logic; token grouping reduces vocabulary-level work in downstream joint inference.Source: §5.2 · p. 12, Table 4 · p. 14

5.3 Analysis

  • Allowing arbitrary property order raises BFCL semantic accuracy from 37.27% to 81.56% for DiffusionGemma and from 72.71% to 81.60% for LLaDA2.2, with 100% schema validity throughout.Native-Opt accuracy changes by only −0.12 and +0.16 points under the corresponding prompt conditions.Source: §5.3 · p. 12
  • On LLaDA2.2’s Any-order common cohort, DConstrain reaches 83.15% semantic accuracy, compared with 82.78% for Native-Opt, 82.60% for LAVE-Opt, and 75.48% for EPIC-Opt.Verification-based methods attain 100% schema validity on this cohort while losing semantic accuracy relative to Native-Opt.Source: §5.3 · p. 15
  • Under Any-order, DConstrain’s overhead is 54.1% for LLaDA2.2 and 49.9% for DiffusionGemma, and warm compilation overlaps GPU model execution.At least 94% of warm-compilation calls finish within the mean forward time in every plotted Figure 2 setting.Source: §5.1 · p. 11, Figure 2 · p. 12, §5.3 · p. 15
  • DConstrain stores local RTN structure and symbolic transition programs, with a 4.74–5.11 MB median recorded payload across three datasets versus 36.86–90.61 MB for DINGO.The runtime experiments measure the cost of deferring work to warm compilation.Source: §5.3 · p. 15, Table 5 · p. 15
  • As property-field count or nesting depth grows, DINGO-Opt increasingly reaches time or memory limits and fails all evaluated cases at depths 5–8, while DConstrain still compiles them.Figure 3 measures these context-complexity trends on a fixed 300-case BFCL subset.Source: §5.3 · p. 15, Figure 3 · p. 16

6 Conclusion

DConstrain keeps stacks and field histories as runtime parameters, enabling exact joint inference without the exponential state expansion that limits finite-state compilers. The appendix formalizes the parser interface and analyzes compiler correctness and costs.

6 Conclusion

  • DConstrain keeps stacks and field histories as runtime parameters, making arbitrary property order practical while preserving exact successors and schema validity.Warm compilation and grammar propagation overlap the model forward pass; token-effect grouping shrinks the graph while preserving the Viterbi optimum and token-labeled path distribution.Source: §6 · p. 16

A Additional Background and Theoretical Analysis

  • The appendix formalizes the parser interface, establishes compiler and weighted-inference correctness, and analyzes compilation and graph-construction costs.Source: A Additional Background and… · p. 20

A.1 Grammar Automata and Parser Configurations

  • Grammar configurations combine local control with a runtime stack; guards, stack operations, and environment updates let shared transition logic operate across contexts.Source: §A.1 · p. 20

A.2 Diffusion Language Models

  • At each denoising iteration, a DLM predicts distributions across positions, and decoding selects updates that can jointly constrain unresolved tokens.Comparisons use identical candidate sets, prefixes, protocols, and boundary conditions.Source: §A.2 · p. 20

A.3 Correctness of Factorized Compilation

The correctness analysis shows that factorized compilation and token-effect grouping preserve normalized token successors source by source. It also establishes preservation for window and complete-output languages under the stated conditions.

A.3 Correctness of Factorized Compilation

  • Normalization removes statically dead configurations, and completed execution preserves finite paths under the stated primitive-operation agreement and resource-completion assumptions.Resource exhaustion is an error, not an empty result.Source: §A.3 · pp. 20–21
  • The summary worklist preserves local endpoints by tracking stack-depth changes, ordered environment operations, and retained tests, then propagating improvements until saturation.For each input binding, saturation preserves reference endpoints cut before the first return to an unknown incoming stack.Source: §A.3 · pp. 22–23
  • At a residual cut, assembly binds the prefix, returns through the actual source stack, and resumes the suffix in the caller, preserving that origin’s reference continuation.The suffix is shorter than the original byte string, enabling the preservation argument by induction.Source: §A.3 · p. 23
  • Completed factorized token execution preserves each source configuration’s normalized successors, while public exit closure restores representation invariants.Equal canonical effects preserve successor sets for each admissible source, but canonical equality is sufficient rather than a complete semantic-equivalence test.Source: §A.3 · p. 24
  • On-demand construction preserves normalized window languages by retaining source–successor edges and token labels rather than combining frontiers as Cartesian products.Factorized acceptance also agrees with raw and normalized semantics on completed queries.Source: §A.3 · pp. 24–25
  • The preservation claims cover logical transitions and token languages, not derivation multiplicities, arbitrary path weights, or resource-truncated results.Raw-to-normalized boundary agreement requires matching boundary predicates; this condition is unnecessary for direct comparison with the normalized reference.Source: §A.3 · pp. 24–25

A.4 Weighted Inference under Token-Effect Grouping

Token-effect grouping preserves weighted inference outcomes under the stated reduction and restoration rules. The guarantees cover both token-labeled path distributions and Viterbi optima, while parsing ambiguity can affect the measure across parser representations.

A.4 Weighted Inference under Token-Effect Grouping

  • Group-sum reduction with conditional token restoration preserves the partition function, token-labeled path distribution, and token marginals under chain or tree inference.The sampling construction recovers the expanded edge conditional, so path probabilities are W(π)/Z.Source: §A.4 · pp. 25–26
  • Group-max reduction preserves the Viterbi optimum under chain or tree composition, and retaining ties recovers all maximizing token sequences.A single argmax and backpointer returns one optimum; matching selected outputs additionally requires the same tie-breaking rule.Source: §A.4 · p. 26
  • Grouped and sequence-level distributions coincide only when accepting-path counts are constant across positive-weight legal sequences; unambiguity is sufficient.Grouping preserves the chosen graph’s measure, not an assumed absence of parsing ambiguity.Source: §A.4 · pp. 26–27
  • These guarantees require the stated weighted conditionals; extra token-dependent scores need corresponding weighted reductions and restoration rules.Greedy selection by group mass is generally not equivalent, and distributional equality does not ensure identical outputs under the same random seed or floating-point reduction order.Source: §A.4 · p. 27

A.5 Complexity Analysis

The analysis contrasts context-expanded representations with factorized programs: finite-state and grammar representations can grow exponentially, while DConstrain stores shared local programs and runtime field histories. The bounds characterize representation growth and avoided replication, not unconditional runtime speedups.

A.5 Complexity Analysis

  • For bounded-depth brackets, a minimal complete DFA needs a separate state for every valid stack plus a sink, but this is a worst-case representation gap, not a universal runtime bound.The stack factor is dmax + 1 when there is only one continuation-frame symbol.Source: §A.5 · p. 27
  • For k required unordered properties, every DFA needs at least 2^k states, and every CFG for the schema language has size 2^Ω(k).The CFG lower bound follows by reducing to the language of all permutations of k distinct property names.Source: §A.5 · p. 27
  • DConstrain uses O(k) local states for the object and shares property guards and updates across all 2^k field histories.The parsing environment stores the set of written properties as a k-bit value.Source: §A.5 · p. 27
  • Construction costs include shared setup, cold state-token work, warm instantiation work, and graph/indexing work; per-entry costs are not assumed constant.Grouping does not remove the work of discovering effects or emitting individual token labels.Source: §A.5 · p. 28
  • Cold assets are reusable only with the same grammar and binding scope; graph reuse additionally needs compatible candidate sets and boundary/protocol conditions.The analysis bounds re-expansion per key and recursive-chain length, not the number or size of keys or total work in branching trees.Source: §A.5 · p. 28

B Additional Experimental Details

B.1 Implementation and Decoding Settings

The experiments use two DLMs in separate serving stacks, with cold compilation measured independently from warm compilation and inference. Each model uses its own stated canvas or block decoding settings.

B.1 Implementation and Decoding Settings

  • LLaDA2.2 runs in SGLang across four GPUs, while DiffusionGemma runs in vLLM 0.28.0 on one GPU per instance; both use BF16 and CUDA Graphs.DConstrain implements cold and warm compilation in C++ and joint inference in CUDA.Source: §B.1 · p. 28
  • Cold-compilation timing uses a single-threaded Intel Xeon Platinum 8575C process, with up to 64 schemas compiled concurrently.Timing ends when the reusable artifact is ready and excludes warm compilation and model inference.Source: §B.1 · pp. 28–29
  • LLaDA2.2 uses 32-token physical blocks with confidence-based MASK updates; decoding stops at accepted EOS or the 2,048-token limit.Budget exhaustion counts as failure; DELETE and SPLIT are disabled.Source: §B.1 · p. 29
  • DiffusionGemma uses 256-token canvases, an entropy-bound sampler, and at most 48 denoising iterations per canvas.Its entropy budget is 0.1, temperature decreases from 0.8 to 0.4, and generation ends at EOS/EOT or the 2,048-token limit.Source: §B.1 · p. 29

B.2 Compilation and Evaluation Settings

The appendix specifies benchmark cohorts and measurement conventions, then reports paired runtime comparisons and implementation optimizations. DConstrain’s Any-order BFCL latency reductions are measured against DINGO-Opt on cases both methods complete.

B.2 Compilation and Evaluation Settings

  • The evaluation pools include 2,495 BFCL cases, 5,754 JSONSchemaBench training schemas, and 1,000 ComplexFuncBench cases.The BFCL pool excludes cases whose schemas admit no valid instance.Source: §B.2 · p. 29
  • DConstrain completes all 2,495 BFCL cases with 100% cold admission, runtime completion, and strict-schema validity under both models and property-order settings.The Any-order DINGO-Opt cold-compilation success rates are 85.81% for DiffusionGemma and 71.30% for LLaDA2.2.Source: §B.2 · p. 29
  • BFCL validity and official semantic accuracy are measured separately; Table 6 latency means use cases successfully completed by both compared methods.Timeouts and exhausted decoding budgets count as runtime failures.Source: §B.2 · pp. 29–30
  • On paired Any-order BFCL cases, DConstrain reduces end-to-end latency by 6.65× for LLaDA2.2 and 46.26× for DiffusionGemma versus DINGO-Opt.Table 6 reports paired successful cases; end-to-end latency is mean request latency.Source: Table 6 · p. 30, §B.2 · p. 30

B.3 Engineering Optimizations

  • Native C++ compilation and packed artifacts reduce interpreter and per-edge object overhead, while CSR stores existing graph transitions for CUDA kernels.Warm compilation overlaps the first model forward pass and does not read model scores; score-dependent operations remain on the critical path.Source: §B.3 · p. 31
  • DINGO-Opt shares DConstrain’s C++ pipeline and CSR representation but retains finite-state compilation; Direct-PDA-Opt interprets reached configurations on demand.Direct-PDA-Opt’s + TG variant adds conservative token grouping before interpretation.Source: §B.3 · p. 31

C.1 Warm Compilation Scaling and Runtime Overlap

Warm compilation grows with runtime-context complexity, but remains small relative to model-forward time across the reported scaling regimes. In a controlled BFCL comparison, DConstrain substantially outperforms direct pushdown interpretation even after token grouping.

C.1 Warm Compilation Scaling and Runtime Overlap

  • On the CFB any-order sweep, median warm-compilation time per 32-token block rises gradually with parameter-field count but remains well below the 9.09 ms mean forward time.The measured cost is additional online work that can overlap with model computation.Source: §C.1 · p. 31, Figure 4 · p. 32
  • At depth eight on BFCL, mean warm-compilation cost per call remains below the approximately 9 ms mean forward time, while end-to-end latency stays comparatively stable.Warm-compilation work rises from depth four to eight as more stack contexts become reachable.Source: §C.1 · p. 31, Figure 4 · p. 32
  • 97.17% of JSONSchemaBench warm-compilation calls stay below the 8.90 ms mean forward time, although the largest call reaches 34.61 ms.The heterogeneous schemas produce a longer tail than the CFB distribution.Source: §C.1 · p. 32
  • With DiffusionGemma’s 256-token canvases, 99.47% of BFCL and 94.20% of CFB warm-compilation calls fall below their respective mean forward times of 26.4 and 26.7 ms.On JSONSchemaBench, 99.3% fall below 25.64 ms, while the maximum observed warm-compilation time is 30.32 ms.Source: §C.1 · p. 32

D.1 Comparison with Direct Pushdown Interpretation

  • In the grouped paired run, DConstrain achieved mean E2E latency of 136.63 ms versus 878.10 ms for Direct-PDA-Opt + TG, a 6.43× speedup.Source: §D.1 · p. 33

D.2 Tree-Parallelized Automata Inference

Tree-parallelized inference can reduce latency on smaller graphs, but its additional computation and memory can dominate on larger ones. The compiled representations remain compact across reported settings, and additional-tokenizer experiments retain high compilation coverage.

D.2 Tree-Parallelized Automata Inference

  • Tree-based inference reduces sequential depth from O(L) to O(log L) by composing adjacent transition operators in a binary reduction tree.For MAP inference, the max-product semiring preserves the Viterbi objective.Source: §D.2 · pp. 33–34
  • 5.58× speedup on the P25 DINGO graph falls short of sequential Viterbi on DConstrain, while tree-parallelized Viterbi is slower on P95 and uses substantially more memory.On P95 DINGO, latency rises from 425.08 ms to 880.38 ms and peak solver GPU memory from 0.08 GiB to 12.84 GiB; tree parallelism also raises latency and memory on the DConstrain graph in both cases.Source: §D.2 · p. 35, Table 7 · p. 35

D.3 Compiled Representations with DiffusionGemma

  • DConstrain’s median recorded memory footprint on DiffusionGemma is 4.10 MB on BFCL, 4.23 MB on JSONSchemaBench, and 4.57 MB on ComplexFuncBench.Corresponding P95 values are 5.39 MB, 28.41 MB, and 5.09 MB; these are recorded native-snapshot payloads, not total process memory.Source: §D.3 · p. 35, Table 8 · p. 36
  • Under arbitrary parameter-field order, DConstrain retains compact local RTN nodes and symbolic transitions where DINGO-Opt produces large context-expanded transition structures.The comparison uses the common successful intersection within each setting, and DConstrain compiles every evaluated case.Source: §D.3 · p. 35, Table 9 · p. 36

D.4 Cold Compilation with Additional Tokenizers

  • With Dream 7B and LLaDA 8B tokenizers, BFCL and ComplexFuncBench compile in all cases, while JSONSchemaBench compiles 281 of 300 schemas.These compilation-only experiments use arbitrary property order; local-state counts are tokenizer-independent, while symbolic transitions, payload, and latency vary with tokenization.Source: §D.4 · p. 36, Table 10 · p. 37

D.5 Failure Analysis on JSONSchemaBench

On JSONSchemaBench, most DConstrain compilation failures reflect unsupported schema semantics, with resource limits the next-largest cause. A targeted audit also shows why frontend acceptance alone cannot establish preservation of original schema constraints.

D.5 Failure Analysis on JSONSchemaBench

  • 789 of 5,754 JSONSchemaBench schemas fail because of semantic-coverage limitations, while 274 fail under resource limits and nine reflect known implementation errors or unresolved behavior.The overall failure rate is 18.6%; semantic-coverage limitations account for 13.7% of the benchmark and 73.6% of failures.Source: §D.5 · pp. 37–38
  • All 305 replayed oneOf and allOf rejections came from the schema-to-parser frontend, but this does not show downstream compilation would succeed after frontend extension.The replay did not invoke the factorized token compiler.Source: §D.5 · p. 38
  • A bounded audit found 124 schemas with complete JSON texts accepted by XGrammar but invalid under the original schema, so frontend acceptance alone does not establish semantic preservation.The audit does not estimate overall semantic accuracy or establish correctness for all accepted schemas.Source: §D.5 · p. 38
  • Warm compilation can still face worst-case exponential growth in nesting depth or other branching, so DConstrain does not guarantee uniform efficiency for arbitrarily deep grammars.The audit tests character-language membership, not compilation against the LLaDA2.2 vocabulary or generation likelihood.Source: §D.5 · pp. 38–39

Related papers

Loading 2610.30920v1…