---
title: 'Pacti: Compositional Analysis Tool'
url: https://www.emergentmind.com/topics/pacti
type: topic
---

# Pacti: Compositional Analysis Tool

Searching arXiv for Pacti-related papers to ground the article in recent sources.
arXiv search query: Pacti assume-guarantee contracts composition diagnostic aerospace
Pacti is a contract-based analysis and design tool for compositional reasoning over assume-guarantee specifications. It was introduced to make the algebra of contracts practical at scale, especially for composition, quotient, refinement, and merging, while keeping computed results small, human-readable, and expressible only in terms of component interfaces [2303.17751]. In subsequent work, Pacti is described as an open-source Python package for compositional reasoning over assume-guarantee contracts and as the computational engine behind workflows for early design exploration and compositional fault diagnosis in cyber-physical systems [2409.02218] [2507.05438].

## 1. Conceptual basis and problem setting

Pacti is grounded in contract-based design. In that methodology, a component is specified by assumptions on its environment and guarantees that the component provides when those assumptions hold. The canonical representation is a contract
\[
C = (A, G),
\]
where \(A\) denotes assumptions and \(G\) denotes guarantees [2303.17751]. A component is an implementation of a contract if, for every environment satisfying the assumptions, the composed system satisfies the guarantees.

The motivation for Pacti is not the invention of a new contract theory, but the implementation gap between mature contract algebra and scalable computation. The central difficulty is that naïve manipulation of contracts often produces formulas much larger and more complex than the originals. That growth degrades readability for engineers and scalability for downstream analysis. Pacti addresses this by combining a contract algebra with implementation principles intended to preserve interface locality and reduce formula blow-up [2303.17751].

The tool is explicitly positioned for two major uses. The first is independent design: decomposing a top-level requirement into contracts for subsystems so that implementations can be developed separately but still compose correctly. The second is concurrent design or viewpoint decomposition: splitting a specification into multiple viewpoints, such as functionality and performance, and combining them algebraically [2303.17751]. This suggests that Pacti is best understood not merely as a verifier, but as a symbolic infrastructure for deriving, transforming, and querying contracts during system analysis and design.

## 2. Contract representation and IO discipline

A central idea in Pacti is the IO contract. In the formulation used across the Pacti literature, an IO contract has the form
\[
(I, O, a, g),
\]
where \(I\) and \(O\) are disjoint sets of input and output variables, \(a\) is a set of assumptions, and \(g\) is a set of guarantees [2303.17751] [2507.05438]. Assumptions depend only on inputs, while guarantees may depend on inputs and outputs. This interface discipline is one of the main scalability devices in the system.

Pacti also adopts a syntactic view of contracts over a term algebra. Instead of representing assumptions and guarantees as monolithic formulas, it uses termlists:
\[
a,g \in 2^T,
\]
with semantics given by conjunction over the listed terms [2303.17751]. This choice mirrors the way industrial requirements are often written, as sets of separate constraints, and makes reduction and elimination more tractable.

The first supported specification theory is polyhedral constraints, that is, linear inequalities over reals [2303.17751]. The aerospace design paper likewise describes Pacti as an open-source package for manipulating polyhedral assume-guarantee contracts, with many specifications written as linear bounds such as
\[
a_1 x_1 + a_2 x_2 + \cdots + a_n x_n \le b
\]
or interval forms [2409.02218]. In that setting, contracts characterize sets of possible implementations rather than a single implementation, which is especially useful in early design when exact architectures or parameter values may not yet be fixed.

For diagnostic use, the same IO structure supports a three-valued interpretation of contract evaluation: **FAIL** when assumptions hold and guarantees are violated, **ACTIVE** when both assumptions and guarantees hold, and **IDLE** when assumptions do not hold [2507.05438]. This distinction becomes important when assigning blame in compositional fault analysis.

## 3. Algebraic operations and computation

Pacti implements the standard algebra of contracts, but its contribution lies in how those operations are computed under IO restrictions. The core operations emphasized in the literature are composition, refinement, quotient, and merging [2303.17751] [2409.02218].

| Operation | Role in Pacti | Representative use |
|---|---|---|
| Composition | Computes a system contract from interconnected component contracts | Deriving a top-level interface contract |
| Refinement | Checks whether one contract is sufficiently strong for another | Validating decompositions or implementations |
| Quotient | Computes a missing component contract from a top-level spec and a partial implementation | Missing-component synthesis |
| Merging | Combines multiple viewpoints over the same interface | Functionality, power, timing, or safety fusion |

For general contracts, the closed-form composition given in the Pacti paper is
\[
C \parallel C' = \big((A A')(A \neg G)(A' \neg G'),\ (G \neg A)(G' \neg A')\big),
\]
and the quotient is
\[
C / C' = \left(A(\neg A' G'),\ (A' G)\neg A\ (A' \neg G')\right)
\]
[2303.17751]. For IO contracts, however, direct use of such formulas is insufficient because the result may mention internal variables outside the visible interface. Pacti therefore post-processes the theoretical result to project it back onto the correct IO signature.

The implementation relies on contextual refinement and relaxation procedures. The Pacti paper highlights the helper procedures `RefineWithContext(t, t', S)`, `RelaxWithContext(t, t', S)`, `Reduce(t, t')`, and `IsRefinement(t, t')` [2303.17751]. Their role is to refine assumptions, relax guarantees, eliminate irrelevant variables, and remove redundant constraints while preserving soundness. Two theorems in that paper justify this strategy: a relaxed composition theorem and a refined quotient theorem.

For IO composition, the output sets must be disjoint,
\[
O \cap O' = \emptyset,
\]
and the visible interface of the composed contract is
\[
I_c = (I \cup I') \setminus (O \cup O'), \qquad
O_c = (O \cup O') \setminus (I \cup I').
\]
The implementation then refines and relaxes terms so the final contract is expressed only over \(I_c\) and \(O_c\) [2303.17751]. A notable property of this implementation is that composition is generally not associative for IO contracts, because the visible interface is recomputed as internal outputs are dropped [2303.17751].

The aerospace paper gives simple illustrations of these operations in practice. In a serial composition example, Pacti eliminates an intermediate variable and returns a contract such as
\[
A:\quad 0 \le i \le 0.2,\qquad G:\quad o' \le i.
\]
In a quotient example, if a top-level system should satisfy \(o_p = 2i + 1\) and a partial subsystem already implements \(o = 2i\), Pacti computes the missing subsystem as
\[
A:\ |o| \le 2,\qquad G:\ o' = o + 1
\]
[2409.02218]. These examples underscore a defining feature of Pacti: it computes explicit contracts, rather than merely certifying satisfiability.

## 4. Implementation principles and theory-specific machinery

The main Pacti paper identifies three implementation principles behind the tool. First, optimal contract operations may be post-processed into relaxed or refined but more usable results. Second, contracts should be represented as lists of requirements rather than single formulas. Third, contracts should obey the IO discipline so that assumptions mention only inputs and guarantees only inputs plus outputs [2303.17751]. These principles are meant to keep results interface-local and computationally manageable.

Pacti’s architecture separates the contract algebra layer from the specification theory layer. The contract algebra layer implements refinement, composition, quotient, and merging. The specification theory layer supplies theory-specific operations such as containment checking, redundancy elimination, and contextual elimination [2303.17751]. This modularity allows the contract machinery to remain theory-agnostic at the algebraic level, while different specification theories can provide their own elimination and simplification routines.

For polyhedral constraints, Pacti instantiates the required procedures using computational geometry and optimization methods. `IsRefinement` becomes polyhedral containment, checked by linear programming; `Reduce` removes redundant inequalities; and `RefineWithContext` and `RelaxWithContext` perform variable elimination by refining or relaxing inequalities [2303.17751]. This is the technical basis for the system’s emphasis on scalability.

The same implementation strategy supports explicit diagnostics when a design is incompatible. In the aerospace paper, replacing a component guarantee \(|o| \le 3\) where another component requires \(|o| \le 0.2\) causes Pacti to report an incompatibility of the form: “Could not eliminate variables ['o'] by refining the assumptions ... using guarantees ...” [2409.02218]. This suggests a broader role for Pacti as an explanatory analysis tool: it does not merely return failure, but exposes which interface-level reasoning step became impossible.

## 5. System analysis and design applications

Pacti has been applied to a range of compositional analysis problems. The original Pacti paper presents case studies in an end-to-end autonomy stack, multi-agent path planning, specification-based synthetic biology, and digital signal processing with fixed-point word-length optimization [2303.17751]. Across these cases, the recurring pattern is the same: local contracts are manipulated algebraically to derive system-level behavior, missing-component specifications, or safe operating envelopes.

In the end-to-end autonomy stack, quotient is used to derive requirements for a perception module from a system-level safety contract and a controller contract. In the multi-agent path-planning case study, dynamics, collision-avoidance, and swapping contracts are repeatedly merged and composed to generate safe move candidates in a grid world, and the implementation was carried out on Robotarium hardware [2303.17751]. In synthetic biology, Pacti is used to evaluate candidate sensors for a NAND-gate-like genetic circuit and to infer the specification of a missing dCas9 subsystem via quotient. In digital signal processing, composed contracts yield system-level error bounds and support iterative word-length optimization, including a design point with \(x_{3n} = 6\) [2303.17751].

A later aerospace paper develops Pacti as an engine for early design exploration. One case study concerns a CubeSat-sized spacecraft performing a small-body asteroid rendezvous mission [2409.02218]. Mission tasks such as **DSN**, **CHRG**, **SBO**, and **TCM** are modeled as contracts over state variables including battery state of charge \(soc\), onboard science data \(d\), cumulative science data \(c\), trajectory estimation uncertainty \(u\), and trajectory progress \(r\). Separate power, science/communication, and navigation viewpoints are specified and then merged. The paper reports schedulability results over sampled design and operation points: for a 5-step scenario, 401 admissible solutions out of 20,000 combinations; for a 20-step scenario, 244 admissible solutions out of 20,000 combinations [2409.02218]. Pacti’s `get_variable_bounds()` and `optimize()` APIs are then used to visualize and optimize battery-state trajectories.

The second aerospace case study concerns preliminary design of an aircraft fuel and thermal management system. Here the system under study is composed from contracts for an electric pump, generator, electric load, heat load, fuel splitter, and heat exchanger, together with an engine model where
\[
h_e = k_e \cdot \dot{m}_e, \qquad k_e = 5000 \,\text{J/kg}.
\]
The specification bounds acceptable temperatures through conditions such as
\[
\underline{T_e} \le T_e \le \overline{T_e},\qquad
T_{in}-\Delta_t \le T_{out} \le T_{in}+\Delta_t,
\]
with \(\Delta_t = 10\) K and \(\underline{T_e}=300\text{ K},\ \overline{T_e}=330\text{ K}\) [2409.02218]. Pacti is used to compare fixed and controlled heat exchanger designs and to embed contract analysis inside a Nelder–Mead optimization loop for component tolerances. A reported feasible design point occurs at altitude 15 km, thrust 20,000 kg, \(\dot{m}_{in}=9.316\) kg/s, and \(\dot{m}_a=0.429\) kg/s, together with optimized tolerance parameters such as \(\epsilon_{ep,w}=0.01\) and \(\epsilon_{hl}=0.06214\) [2409.02218].

These applications indicate a common methodological role: Pacti relates local component specifications to system-level behavior by eliminating internal variables, computing explicit contracts over external interfaces, and enabling design-space exploration without requiring a fully detailed implementation.

## 6. Provenance-aware diagnosis, limitations, and disambiguation

A more recent line of work uses Pacti for compositional fault diagnosis in cyber-physical systems [2507.05438]. In that setting, each component is associated with an assume-guarantee contract, the system-level contract is computed compositionally, and a violated system-level guarantee is traced back through the composition structure to identify responsible components and the specific predicates involved. The framework introduces a composition graph whose vertices correspond to component and composed terms, and a diagnostics graph formed by the union of intermediate composition graphs. A diagnostics map
\[
\mathtt{CM}
\]
returns the leaf terms that influence a violated top-level guarantee [2507.05438].

The technical reason Pacti is useful here is not only that it composes contracts, but that its elimination and refinement procedures can expose which context predicates contributed to a composed result. The paper explicitly uses \(\textproc{ElimVarsbyRefinement}(\cdot)\) and a recursive trace procedure to distinguish two cases: a violated guarantee under satisfied assumptions, which marks a component as faulty, and a violated assumption, which must be traced backward to other components [2507.05438]. In a simple 3-component example, the method checks only 6 terms rather than all component terms; in a larger autonomous-vehicle example inspired by the DARPA Urban Challenge, the composed system contract has 212 guarantee terms and 656 total component-level terms, yet diagnosis requires checking only 50 component-level statements, about 7.6% of all terms [2507.05438]. A plausible implication is that provenance tracking extends Pacti from a design-time algebraic engine into an explainable debugging substrate.

The literature also makes clear that Pacti’s present strengths are tied to its assumptions. Current support is centered on polyhedral constraints [2303.17751] [2409.02218]. The scaling strategy depends on IO contracts, contextual elimination, and reduction. This suggests that expressiveness and tractability are balanced deliberately, with interface-local linear specifications favored over unrestricted formulas.

Finally, Pacti should be distinguished from similarly named but unrelated artifacts. **Pact** is a choreographic language for agentic ecosystems that extends choreographies with strategic choice, preferences, and uncertainty [2605.03143]. **PACCs** refers to private, anonymous, collateralizable commitments in DeFi [2301.12818]. **PACT** is also the name of a Pareto-aware controller for triggered active learning in SOC alert streams [2605.22324]. In the assume-guarantee literature, however, **Pacti** denotes the contract-analysis tool and package centered on composition, quotient, refinement, merging, and related compositional reasoning [2303.17751].

Source: https://www.emergentmind.com/topics/pacti