Generic platforms often fail in one of two ways. They know so little about the work that every customer starts from a blank page, or they hard-code one use case so deeply that the next one requires a fork.
Proxima uses workflow packs to avoid both.
A workflow pack is an executable definition of one operational workflow. It tells the platform what the data means, which facts to derive, how decisions are made, what actions exist, and how results should be scored. The runtime supplies the common machinery. The pack supplies the domain.
Shared Proxima runtime Events · Cases · Decisions · Actions │ ┌────────────────┼────────────────┐ │ │ │ Shipment pack Lending pack Invoice pack ETA and carrier Documents and Orders and exceptions policy checks payment terms
This split is more than a way to organise files. It is the product boundary between reusable infrastructure and domain-specific operational meaning.
What belongs in a pack
The first Proxima packs are stored as versioned YAML definitions. A pack contains several related contracts rather than one large prompt.
Field definitions describe the canonical data the workflow needs. They include types, required fields, accepted aliases, and normalization rules.
Derived fields turn source facts into operational concepts. A promised time and current ETA become a delay in minutes. Revenue and customer tier may become an exposure band. A document list may become a completeness score.
Decision rules classify a case and propose a next action. Rules can use nested conditions and explicit priority, and each evaluation produces a trace.
The action catalogue defines the actions the workflow is allowed to propose. A decision cannot invent a tool call that is absent from the catalogue.
Outcome mappings connect historical actions and results to a common vocabulary so replay can compare like with like.
Scoring definitions say how the diagnostic should report data quality, decision agreement, coverage, and business relevance.
Together, these files form a domain model that both engineers and operational specialists can review.
We considered a more flexible design in which each workflow could supply its own service code. It would handle unusual requirements quickly, but every workflow would gradually acquire a different deployment path, test harness, and operating model. Packs are more constrained by design. A workflow can express domain variation without replacing the platform underneath it.
The runtime remains deliberately ignorant
The core runtime does not contain a Shipment class or a special branch for lending. It works with an event, a workflow identifier, a payload, derived fields, a decision result, and an action proposal.
That boundary is useful. When a shipment pack calculates eta_delay_minutes, the runtime only needs to know that the field can be computed and then referenced. When a loan triage pack calculates an exposure band, the same derived-field engine performs the work.
The decision engine follows the same pattern. It evaluates the selected pack’s rules and resolves the winning decision. The content changes. The execution contract does not.
Generic does not mean identical
Different workflows need different screens, terminology, and evidence. A logistics operator cares about lane, carrier, ETA, and service level. A lending reviewer cares about applicant details, document completeness, policy exceptions, and exposure.
Those differences should be visible. They simply should not require separate products.
The operations console can render workflow-specific fields and actions from the selected pack while preserving a shared navigation model: cases, events, decisions, actions, exceptions, and outcomes. An operator sees the language of the job. The platform team maintains one console and one runtime.
Packs also create a testing boundary
A workflow definition should be releasable software, not an informal configuration change.
Each pack can be validated before it runs. Referenced fields must exist. Derived fields must use supported operations. Rule actions must appear in the action catalogue. Fixtures can cover common cases and awkward edges. Historical data can then be replayed against the candidate version.
This makes changes easier to reason about. If a priority threshold moves from two hours to ninety minutes, the team can see exactly which historical cases change classification. If a new action is introduced, tests can verify which rules are able to propose it.
Versioning also protects the audit trail. A decision should point to the workflow version that produced it, even after the current pack has moved on.
Not every change should be released in the same way. Adding a report label is different from changing a priority threshold that redirects live work. The pack gives Proxima a unit to validate, replay, review, and release according to the impact of the change.
Where models fit
Not every part of a workflow can be expressed as a rule. An email may need to be classified, a document may need to be interpreted, or an unusual case may need a recommendation based on several pieces of text.
That does not make the whole workflow a prompt.
A model-backed step should have a named input contract and a bounded output schema. Its result becomes another fact or decision input that the pack can use. The action catalogue and runtime lifecycle remain unchanged.
This keeps model behaviour local. Teams can evaluate or replace one classifier without rewriting the event contract, operator queue, or execution adapters.
It also prevents workflow definitions from becoming prompt collections. The model performs a named interpretation task; the pack still owns what that interpretation means for the operation.
Adding a second workflow
The real test of this architecture is not whether the first logistics workflow works. It is whether a structurally different workflow can be added without changing the core engine.
The same diagnostic machinery is built to carry across workflows: shipment exception handling and loan application triage share the profiling, mapping, and replay steps. Their field catalogues, derived values, rules, actions, and outcomes differ. Their execution path does not.
There will always be cases that require a new platform capability. A workflow may need timers, multi-step compensation, document extraction, or a new class of action adapter. Those additions should strengthen the shared runtime rather than become hidden code for one customer.
Workflow packs make that distinction visible. Domain knowledge stays specific. Infrastructure becomes reusable. That is how a product can support many use cases without becoming a collection of unrelated dashboards and scripts.