LeanArchitect: Formal & Agile Architectures

• LeanArchitect is a dual-framework concept that automates Lean 4 blueprint extraction and supports agile system architecture development in safety-critical sectors.
• It employs a unified dependency graph via annotated [blueprint] attributes to integrate formal proofs with human-readable LaTeX documentation.
• The workflow enhances human-AI collaboration by providing automated proof-status tracking, consistent artifact synchronization, and compliance with ARP4754A.

LeanArchitect refers to two distinct, field-defining frameworks: (1) a Lean 4-native package for automating blueprint generation in large-scale mathematical formalization, and (2) a model-based, lean system architecture development workflow suited for agile engineering contexts, particularly those adhering to ARP4754A in safety-critical industries. Both approaches emphasize rigorous artifact traceability, reduction of duplication, and tool-mediated integration for human and automated agents, but they operate in different domains.

1. LeanArchitect in Formal Mathematical Blueprint Automation

LeanArchitect, as introduced for Lean 4, is a Lean package designed to unify informal $\LaTeX$ blueprints with formal Lean code into a single, source-of-truth workflow for collaborative mathematics formalization. The system directly addresses the traditional decoupling between human-readable blueprints (structured $\LaTeX$ documents) and Lean modules, mitigating duplication and facilitating scalable integration with AI-based automation tools (Zhu et al., 30 Jan 2026).

Design Goals and Formal Structure

The principal objectives are:

• Eliminate redundancy between informal expository blueprints and formal Lean developments.
• Maintain an explicitly fine-grained dependency graph recording both mathematical statements and proof status.
• Provide deterministic, incremental data export (LaTeX, JSON) for CI systems, AI theorem provers, and downstream automation.

Formally, LeanArchitect constructs a dependency graph $G = (V, E)$, where $V$ denotes blueprint nodes—each corresponding to a Lean declaration tagged with a dedicated @[blueprint] attribute, and $E \subseteq V \times V$ encodes use-dependencies. Internal node metadata comprises the LaTeX label, informal statement/proof documentation, dependency sets, and a Boolean proof flag $\mathit{leanOk}$ indicating completed proofs (i.e., absence of sorry axioms).

2. Declarative Annotation and Extraction Mechanisms

The system introduces:

• The @[blueprint] attribute in Lean, which attaches rich blueprint metadata (LaTeX label, statements, proofs, discussions, and dependency annotations) to definitions and theorems.
• The blueprintExt environment extension collects all annotated declarations, constructing the internal artifact graph.
• A Lake “blueprint” facet, which orchestrates extraction and module-by-module rendering of blueprint data as LaTeX fragments via \inputleannode{…} for seamless inclusion in human-readable documents.

The annotation workflow is exemplified by:

@[blueprint "thm:add-comm" (statement := /-- Addition in ℕ is commutative. -/)] theorem MyNat.add_comm (a b : MyNat) : a + b = b + a := by /-- By induction on `a` using zero_add and succ_add. -/ induction a with | zero => exact b.zero_add | succ a ih => sorry_using [MyNat.succ_add]

This automatically infers dependencies and populates blueprint nodes, which are then rendered into LaTeX environments and exported for synchronization.

3. Metadata Extraction, Export, and Consistency Guarantees

LeanArchitect's extraction pipeline incorporates:

• Attribute handler logic that analyzes type and value fields of tagged declarations, computes dependency sets, determines proof completion, and constructs structured node entries in the internal graph.
• Incremental export routines via a Lake facet, ensuring only modules with changed blueprints regenerate their LaTeX outputs.
• Completeness and consistency properties:
  • Consistency: For every edge $(u \to v) \in E$, it holds that $u$ is referenced in the “uses” set of node $v$.
  • Completeness: Any proof node without a sorry axiom guarantees the $\leanok$ label in exported LaTeX, supporting proof-status tracking.

4. Case Study: Formalizing the Multivariate Taylor Theorem

A representative application is the formalization of the multivariate Taylor theorem. The process demonstrates automatic elimination of manual dependency lists, surfacing incomplete proofs and inconsistencies. The case study involved GPT-5 Pro generating annotated skeletons, with further automated proof attempts by the Aristotle prover. The resulting blueprint graph clearly visualized state, dependencies, and status (proved via Aristotle: green; manual: red). For the Taylor theorem, this workflow removed 12 lines of manual \uses, exposed one missing dependency, and provided accurate proof-status tracking over multiple nodes (Zhu et al., 30 Jan 2026).

5. Integration with Human–AI Formalization Workflows

A core feature is LeanArchitect’s facilitation of human–AI collaboration. The system:

• Exposes the full blueprint state as a JSON dump for AI ingestion.
• Supports round-trip workflows in which LLMs (e.g., GPT-5 Pro) propose Lean blueprint modules using extracted dependency graphs, and automated provers (e.g., Aristotle) attempt to discharge sorry-tagged subgoals.
• Provides immediate, programmatic feedback loops, so humans and AI iteratively close remaining proof gaps.

Pseudocode for integration:

import json, subprocess, openai bp = json.load(open("blueprint.json")) prompt = f"Refine this blueprint: {bp['nodes']}" response = openai.ChatCompletion.create(model="gpt-5-pro", prompt=prompt) with open("draft.lean","w") as f: f.write(response.choices[0].text) subprocess.run(["lean","--run","fill_sorry","--file","draft.lean"])

6. Advantages, Limitations, and Prospective Extensions

Advantages:

• Complete elimination of manual $\LaTeX$ ↔ Lean synchronization.
• Fine-grained, automatic dependency tracking and proof-status management.
• Full compatibility with legacy blueprint workflows.
• Natural JSON-based interface for large-scale AI co-development.

Limitations:

• Embedding $\LaTeX$ within .lean files is not IDE-friendly due to lack of syntax highlighting.
• Declarations are restricted to unique blueprint labels.
• Additional build system complexity.
• Informal nodes outside Lean must still be managed manually.

Candidate extensions include integrating richer prover feedback for LLM guidance, IDE plugins for annotation editing, support for multiple blueprint overlays, and bidirectional $\LaTeX$-to-Lean sync (Zhu et al., 30 Jan 2026).

7. LeanArchitect Workflow in Agile, Safety-Critical System Architecture

The “LeanArchitect” process in systems engineering is a four-step, MBSE-centric iterative workflow designed for ARP4754A-aligned development in aviation, emphasizing automation and minimal manual burden (Dollinger et al., 2021). The cycle proceeds as follows at each hierarchical level:

1. Define System Functions: Requirements analysis, function allocation, and FDAL assignment using System Composer, Polarion, and SimPol integration.
2. Build Functional Architecture: Graphical and matrix-model artifact creation, ensuring correct stereotype/connector conventions through model-validation rules.
3. Derive Physical Architecture & Allocations: Allocation of functions to physical actors; automated model checks for consistency and completeness.
4. Author Item-Level Requirements: Polarion-based, trace-linked authoring of hardware/software requirements with full backtrace to higher-level functions.

Supporting routines maintain continuous requirements management and safety assessment, leveraging traceable, bi-directional model exports.

Compliance and Automation Features

The workflow achieves full or partial coverage of key ARP4754A objectives (functions definition, allocation, system/item requirements, traceability) and partial automation of safety assessment via FHA/PSSA model re-use. Automation strategies include script-driven trace generation, model validation, and automatic safety model synchronization, substantially supplanting traditional manual review cycles.

Case Study: Experimental Autopilot

Applied to an Experimental Autopilot, the process demonstrated artifact traceability from CONOPS to item requirements and real-time integration of safety findings. Outcomes included early error detection and elimination of manual identifier management, with reported reductions in late-cycle defect introduction and review overhead (Dollinger et al., 2021).

---

In both domains, LeanArchitect frameworks exemplify the integration of formal artifact graphs, programmatic metadata annotation, and automated consistency guarantees, supporting both human and AI agents in rigorous, traceable development workflows (Zhu et al., 30 Jan 2026, Dollinger et al., 2021).