qsdsan-exposan-architecture

To change repository structure safely across QSDsan and EXPOsan, follow the documented package boundaries, canonical unit_operations and process_models namespaces, and deterministic development rules so paired repository modifications preserve API compatibility and prevent breaking changes.

Modeling capabilities belong in QSDsan when they serve the engine broadly, while case-study and system specifics should remain in EXPOsan. The change management rules guide this split to maintain correct package boundaries and prevent dependency violations between the paired repositories.

Per-flowsheet LCA registry patterns require using the recommended context manager and removing deprecated clearing patterns. Correct LCA and flowsheet isolation ensures deterministic registry behavior and prevents cross-flowsheet contamination when running systems models.

Unit classification into bst, static, or dynamic categories follows the canonical public namespace conventions documented for QSDsan. Applying these conventions correctly when modifying process_models ensures dynamic unit behavior and unit_operations remain consistent with the package architecture.

Documentation authoring for QSDsan and EXPOsan tutorials requires following a strict notebook structure and style rules. These documentation standards keep tutorial artifacts consistent and buildable, ensuring CI integration and examples remain valid across both repositories.

Architecture changes fail CI integration when they violate package boundaries, namespace conventions, or dependency policy. Review your proposed change against the package map, release checklist, and canonical API exports to identify exactly what tests and docs need adjustment.