IR→DPO Workflow: Metadata & Code Alignment

• IR→DPO workflow is a data-centric pipeline that integrates repository submissions and machine learning code processes using schema-first methods.
• It employs a four-tier architecture and a five-phase lifecycle to ensure rigorous metadata validation, preservation packaging, and executable compliance.
• Direct Preference Optimization (DPO) within the workflow matches LLM outputs to execution criteria by leveraging structured IR extraction and preference pair construction.

An IR→DPO workflow is a schema-first, data-centric pipeline for aligning either repository submission processes or machine learning models to strict requirements of metadata integrity, semantic expressiveness, and executable compliance. In institutional repository contexts (0706.0306), IR→DPO refers to a multi-layered submission-to-deposit workflow for digital preservation objects, implemented via configurable Java-based business process engines with SOAP-integrated repositories. In LLM-centric scientific frameworks (Wang et al., 15 Jan 2026), IR→DPO signifies the transformation of verified domain-specific code artifacts (“tool decks”) into intermediate representations (IRs), and the subsequent construction of preference datasets for direct optimization of executable outputs. This workflow bridges high-level task or instruction tuning with robust document or code preservation, ensuring both semantic and syntactic correctness at scale.

1. Architectural Foundations

The classical IR→DPO pipeline is founded on a four-tier architecture (0706.0306):

• User Interface Tier: Implemented via JSP/JSF, provides front-end forms and workflow controls.
• Business Logic Tier: Java EJBs/Backing Beans orchestrate process state, invoke roles, and manage transitions.
• Integration Tier: Two sub-paths exist:
  • Fedora-SOAP Stub: Handles protocol-level ingest, update, and query via Axis-generated minimal bindings.
  • jBPM Context: Manages business process execution, including task and action routing.
• Persistence Tier: Fedora Repository (object store) and MySQL DB (process state) serve as back-end, typically hosted within Tomcat containers.

In the LLM framework (Wang et al., 15 Jan 2026), IR→DPO attaches these concepts to data processing streams rather than microservice orchestration. Here, verified “tool decks” undergo automatic IR extraction, JSON serialization, and batch augmentation prior to preference dataset construction.

2. Workflow Lifecycle and Formal Definitions

The IR→DPO submission workflow is partitioned into five distinct phases (0706.0306):

1. Submission & Ingest: Authors submit object and metadata. jBPM nodes: start-state, fill-in-metadata, ingest-action.
2. Metadata Extraction & Validation: System extracts/validates Dublin Core fields, checksum verification. Decision node assigns outcome.
3. Preservation Packaging: Content + metadata bundled into FOXML/BagIt packages.
4. Review & Approval: QA roles validate, can route back for author rework or publish directly.
5. Final Deposit & Publication: System deposits final object, modifies/activates data streams.

Each phase is encoded as jPDL/BPMN nodes with typed process variables and formal transition conditions. Example minimal process-definition.xml exhibits swimlanes for authors, system, and reviewers, with transitions conditional on Boolean outcome variables.

In code-centric settings (Wang et al., 15 Jan 2026), IR extraction parses tool decks to structured records. Diversification and error-injection algorithms create variant sets obeying strict fact-card invariance and executable round-trip tests, including single-fault negative samples for preference optimization.

3. Intermediate Representation and Diversification

Intermediate Representation (IR) functions as the canonical schema for granular process, content, or code attributes (Wang et al., 15 Jan 2026):

• IR Fields: dimension, materials, regions (ordered Boolean op tree), contacts, doping profiles, mesh refinement, export directives, fact card.
• Extraction: Automated parsing from source artifact to normalized JSON; stripping aliases and canonicalizing numeric expressions.
• Diversification: Via Diversify(IR_flat) algorithm, generates commutative swaps, numeric jitter (unit-aware, within solver tolerance), toggled optionals. All variants undergo:
  • Fact-card invariance: Region and contact counts, Boolean-op signature.
  • Round-trip executability: Deck re-render and syntax validation (sde –S for TCAD).

This guarantees semantic equivalence while exposing variation, crucial for constructing robust, preference-guided learning datasets.

Workflow Context	IR Definition	Diversification Criterion
Repository (0706.0306)	Metadata/forms/process state	BPMN/jPDL transitions, task nodes
Domain-specific LLM (Wang et al., 15 Jan 2026)	Geometry/material/doping/mesh/export	Fact-card invariance, syntax pass/fail

4. Direct Preference Optimization (DPO) Objective

DPO enables direct alignment of LLM outputs with executable validity, substituting supervised preference pairs for classic RL reward models (Wang et al., 15 Jan 2026):

• Preference Probability: For $(x, y^+, y^-)$, $$P_\theta(y^+ \succ y^-|x) = \sigma(r_\theta(x, y^+) - r_\theta(x, y^-))$$ where $r_\theta(x, y) = \log \pi_\theta(y|x)$.
• DPO Loss: $$L_{DPO}(\theta) = -\mathbb{E}_{(x, y^+, y^-)\sim D}[\log \sigma(r_\theta(x, y^+) - r_\theta(x, y^-))]$$.
• Gradient: Flows directly through the difference of output log-probabilities, applied over token sequences.

This paradigm eschews policy gradient and separate reward modeling; instead, preference pairs (instruction, correct code, fault-injected negative) drive stable, supervised fine-tuning.

5. Preference Pair Construction and Data Packaging

For each diversified IR, the workflow generates:

• Instruction ($I$): Natural-language directive describing the canonical transformation, e.g. “Construct a 2D silicon region…”
• Chain-of-Thought (COT): Stepwise breakdown of logic (geometry → doping → mesh → export).
• Positive Code Sample ($c^*$): Deterministically rendered, alias-free script.
• Negative Code Samples ($\hat{c}_j$): Each violates a single invariant—numerical, procedural order, omission, or cross-sample impostor.

Validation ensures $c^*$ passes the syntax and fact-card checks; all $\hat{c}_j$ fail at least one. Packaged entries serialize $(I, COT, c^*, [\hat{c}_1, \hat{c}_2, ...])$ in JSON for direct use in DPO training.

6. Integration, Administration, and Extensibility

The IR→DPO workflow is configurable at both process and data levels (0706.0306):

• Adding Steps: New BPMN tasks/actions via graphical process designers (Eclipse/GPD), assignment to custom swimlanes.
• Form Modification: JSF/JSP front-end extensions update process variables and form bindings.
• Scope Configuration: Bean registration and POST-back persistence via faces-config.xml.
• Deployment: Modular process pipelines (.par bundles), handler classes, dynamic servlet or graphical deployment.

In open-source LLM settings, all extraction, augmentation, and serialization are reproducible from released code and datasets (Wang et al., 15 Jan 2026).

7. Limitations, Soundness, and Evaluation

Considerations for robust IR→DPO deployment include:

• Workflow Soundness: BPMN/GPD lacks formal reachability/dead-path analyses; static checking (e.g., Petri-net) recommended.
• Scalability: For repositories, Tomcat clustering and pooled DB access; for code-centric LLMs, microservice offloading of heavy checks.
• Security: Replace basic auth with WS-Security in SOAP stubs; sanitize user inputs; enforce repository ACLs.
• Metadata & Executability Standards: Controlled vocabularies, upgrade from FOXML to PREMIS/METS, OAI-PMH interoperability.
• Empirical Results: In TCAD, TcadGPT with IR→DPO achieves 80% pass@3 for executable script production versus 0% for unaligned baselines (Wang et al., 15 Jan 2026).

A plausible implication is that schema-first IR extraction and equivalence-preserving diversification substantially raise executable alignment and domain compliance for specialized applications, especially under data scarcity.

8. Generalization and Domain Portability

The IR→DPO pattern generalizes to domains with analogous requirements:

• In repository preservation, the system is parameterized by metadata schema and object lifecycle transitions (0706.0306).
• In scientific code generation, the workflow applies provided verified scripts exist and an executable IR can be defined for target solver syntaxes (Wang et al., 15 Jan 2026).

Consistent improvements in both syntactic and semantic benchmarks are observed when applying IR→DPO recipes to new verticals such as finite element solvers.

This suggests a robust, reproducible pathway for high-integrity process and model alignment in both digital preservation and executable AI domains.