# Workflows, jobs and automation

Compose repeatable work with explicit state, persistence, branching and operation-execution responsibilities.

Source snapshot: bcc79fcc27c4d801c2119bef81ddcce7b4e86498

## Choose composition before scheduling

WorkflowComposer supplies tenant-aware composition, validation, a runner, state and persistence adapters. Its runner requires supplied operation execution and state persistence. A provider-specific scheduler belongs at a different boundary. The workflow-orchestration module adds reusable product-facing views and lifecycle/approval behavior. Start by deciding whether your task is to describe a graph, execute selected steps, schedule work durably, or present an operator view; that decision identifies which package to open first.

Source: https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/platform/delivery/workflow-composer/README.md

## Keep graph changes deterministic

The maintained composer applies extensions in stable priority order, rejects duplicate injected step IDs and invalid anchors, and checks hidden-step overlays so they do not orphan the remaining graph. Metadata and annotations are merged into the composed result. These details matter when adding a tenant or product extension: inspect the resulting graph and its references, not just the added step. Keep step identity stable enough for state, traces and operator actions to refer to the same work.

Source: https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/platform/delivery/workflow-composer/README.md

## Make execution and persistence visible

The canonical leaves include workflow context, SLA monitoring and SDK error conversion as well as validation and shared task validators. Choose the state store and operation executor the host actually supplies. A saved plan, a running instance, a retried step and a completed external effect are different states. Capture outcomes and failure paths at the point where callbacks or adapters return. For automation that can improve or regenerate itself, use the separate governed proposal and promotion lifecycle rather than replacing an active workflow silently.

Source: https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/platform/delivery/workflow-composer/README.md

## Follow an existing graph

Record the entry, operation references, branch conditions and terminal outcomes. Inspect one extension and compare the composed graph to its base. Check which registry and source version resolve each step.

Source: https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/platform/delivery/workflow-composer/README.md

## Select state and execution adapters

Begin with the maintained memory/file or supplied adapter appropriate to the example. Identify the durable store and scheduler needed for the intended host before claiming restart or retry guarantees.

Source: https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/platform/delivery/workflow-composer/README.md

## Review interruption and recovery

Use existing tests or fixtures to inspect a failed step, repeated delivery and cancelled instance. Confirm that persisted state and returned results explain what happened and that retry behavior belongs to an explicit host/runtime contract.

Source: https://github.com/lssm-tech/contractspec/blob/bcc79fcc27c4d801c2119bef81ddcce7b4e86498/packages/platform/delivery/workflow-composer/README.md

## Packages

- [@lssm-tech/lib.bus](https://lssm.co/docs/packages/lib.bus/): Event bus and messaging primitives
- [@lssm-tech/lib.jobs](https://lssm.co/docs/packages/lib.jobs/): Background jobs and scheduler module for ContractSpec applications
- [@lssm-tech/lib.workflow-composer](https://lssm.co/docs/packages/lib.workflow-composer/): Tenant-aware workflow composition helpers for ContractSpec.
- [@lssm-tech/lib.orchestration-spec](https://lssm.co/docs/packages/lib.orchestration-spec/): Provider-neutral cross-domain orchestration semantics for autonomous-company workflows.
- [@lssm-tech/lib.self-improving-system-runtime](https://lssm.co/docs/packages/lib.self-improving-system-runtime/): Deterministic policy, compilation, and replay runtime for governed self-improvement.
- [@lssm-tech/module.self-improving-system](https://lssm.co/docs/packages/module.self-improving-system/): Headless orchestration for governed, goal-bound self-improvement.
- [@lssm-tech/lib.sop-runtime](https://lssm.co/docs/packages/lib.sop-runtime/): Living SOP generation, qualification, drift, health-trigger, and workflow compiler runtime.
- [@lssm-tech/module.workflow-orchestration](https://lssm.co/docs/packages/module.workflow-orchestration/): Workflow orchestration module — board, DAG, dashboard, composer, state-machine, instance lifecycle, approvals.
- [@lssm-tech/integration.eve](https://lssm.co/docs/packages/integration.eve/): Contained EVE runtime adapter for ContractSpec agents
- [@lssm-tech/integration.self-improving-system-transport](https://lssm.co/docs/packages/integration.self-improving-system-transport/): Generated transports for governed self-improvement
- [@lssm-tech/integration.workflow-devkit](https://lssm.co/docs/packages/integration.workflow-devkit/): Workflow DevKit compiler and runtime bridges for ContractSpec workflows
- [@lssm-tech/bundle.self-improving-system](https://lssm.co/docs/packages/bundle.self-improving-system/): Headless controllers and operator view models for governed self-improvement
