Orchestrate data, rules, models and people

Separate system responsibilities

Combining collection, business logic, generation and execution in one call makes the system impossible to reason about. Separate at least four layers: available facts, explicit rules, model inference and the final action.

This separation lets a team replace one part without rewriting the rest. It also localizes failure: missing data, conflicting rules, uncertain output, skipped approval or failed execution. Legible orchestration is first a diagnostic tool.

• Data: what the system knows
• Rules: what must always hold
• Models: what is inferred or generated
• People: what needs judgment
• Actions: what changes the outside world

Treat the model as a fallible component

A model returns a proposal within a context of validity, not universal truth. Its contract should define accepted inputs, output shape, refusal cases, acceptable latency and fallback behavior.

Do not let the model invent its own permissions. Authorization, limits, recipients, workflow states and irreversible actions belong in deterministic code. The model may suggest; the system decides whether it is allowed to act.

Put people where judgment changes the result

Human approval everywhere creates a queue, not safety. No approval creates a black box. The right position depends on error cost, reversibility and uncertainty.

The arbitration interface should expose what a person needs to decide quickly: source, proposal, triggered rule, uncertainty and consequence. An approve button without context turns an operator into an administrative rubber stamp.

Keep a trail that helps operations

A useful record connects an input, rule or model version, decision, actor and action. It answers operational questions: why did this message go out, who changed this status, which data was missing, and can the action be reversed?

Traceability is not only a compliance concern. It shortens diagnosis, enables version comparison and turns exceptions into material for product improvement.