Quick & Dirty Fix: the Triple Crown.

1. Definition of a Quick & Dirty Fix

A Quick & Dirty Fix (QDF) is a deliberately narrow, contract-driven automation intervention that removes one recurring operational friction within an existing workflow. It is neither careless implementation nor a disguised platform programme. “Quick” means that its request, operation, outcome, and value can be understood promptly. “Dirty” means pragmatic and intentionally limited: it implements only the controls needed for its stated operational boundary.

A QDF has an explicit trigger, defined input and output contracts, a limited execution boundary, observable results, isolated failure handling, and a clear stopping condition. Its contract says both what it will do and what it will refuse, defer, or hand to a person. A QDF can contain more than one activity when the activities are inseparable for its bounded outcome; it should not acquire unrelated workflow responsibilities.

2. Problem class

QDFs address recurring, low-to-moderate-complexity operational friction where a durable product or broad workflow redesign would be disproportionate. Examples include extracting fixed fields from repeated requests, checking a configuration against policy, preparing a constrained draft, routing an intake item, or assembling a regular operational summary.

The problem needs a recognizable demand signal, sufficiently stable inputs, a useful observable outcome, and a tolerable failure mode. It is a poor fit for open-ended judgement, long-running cross-team coordination, unrestricted authority, or an unbounded set of integrations.

3. Essential properties and boundaries

Stateless decision logic and short-lived execution state are preferred because they simplify replay and replacement. Durable case state is justified when the QDF must wait for events, retain evidence, or coordinate review.

4. BPMN: prescribed process behavior

BPMN specifies prescribed process behavior. It defines the start event, ordered activities, service interactions, gateways, success path, error path, and end events. It answers: when this execution is started, what flow is performed and how does it complete?

Use BPMN to make the operational path executable or reviewable, including boundary error events and explicit completion. It does not model a request’s full evolving context or a large table of business policy.

5. CMMN: case context

CMMN specifies case context. It defines the execution instance, case file and data, event-driven work, discretionary interventions, milestones, and criteria that make work available. It answers: what is known about this specific situation, what may happen next, and what work becomes available as events and data change?

Use CMMN when the QDF needs contextual state, such as an intake case awaiting evidence, a reviewer’s intervention, or a delivery milestone. A CMMN task may invoke a BPMN process; it does not replace the detailed sequence of that process.

6. DMN: decision logic

DMN specifies decision logic. It defines stateless business rules, eligibility checks, routing, thresholds, classifications, and outcome selection. It answers: given declared inputs, what decision outcome applies?

Use a DMN decision service for policy that must be inspectable and independently testable. It receives declared facts and returns a result; it does not create a case, execute service calls, or manage exceptions.

7. Unified Triple Crown operating model

One bounded QDF keeps the request context, prescribed execution, and policy outcome distinct while sharing explicit contracts, observations, and a terminal condition.

8. UML diagram set

These diagrams show how the QDF is specified, assembled, run, observed, isolated on failure, and brought to a terminal outcome.

9. Worked operational example

Intake takeaway curator. A team receives meeting notes and needs a concise, owner-tagged takeaway email. The QDF starts only for the recognized “curate takeaways” trigger with notes and a recipient. Inputs require non-empty notes, an authorized requester, and a delivery target; outputs include a correlation ID, structured takeaways, delivery status, and any review reason.

• CMMN: holds notes, requester, recipient, decision result, draft, and observations; incomplete notes or marginal confidence make review available.
• BPMN: validates, evaluates eligibility, invokes constrained curation, validates the returned format, delivers, and ends; boundary errors are isolated.
• DMN: returns AUTOMATE, HUMAN_REVIEW, or REJECT from explicit facts. It does not call AI or send email.

AI is a constrained processing capability: it receives approved notes and formatting instructions, returns a schema-conforming draft, and has no authority to choose recipients, manage the case lifecycle, invoke arbitrary tools, or decide delivery.

10. Principles, constraints, and anti-patterns

Principles and constraints

1. Narrow and localized scope: remove one named friction; keep authority and integrations local.
2. Demand-triggered execution: prefer an explicit request or event unless a schedule is the actual contract.
3. Minimal necessary complexity: model paths, data, and controls needed for safe operation.
4. Explicit contracts: validate inputs, outputs, permissions, time limits, and side-effect boundaries.
5. Stateless decisions where possible: use declared facts and retain case state only when context needs it.
6. Fail fast and visibly: preserve a clear reason and correlation ID.
7. Contain failures: scope retries, alerts, compensation, and review to one execution.
8. Integrate rather than replace: use existing tools and handoffs through explicit interfaces.
9. Replaceability: make the QDF easy to retire, revise, or promote.
10. Constrained AI: limit inputs, outputs, permissions, and validation.

Anti-patterns

• Calling a broad agent loop a QDF with no defined trigger, authority, or stop condition.
• Treating BPMN, CMMN, or DMN as substitutes for one another.
• Using “quick” to justify hidden side effects, silent errors, or untraceable delivery.
• Encoding case context in an opaque decision table, or policy thresholds solely in process gateways.
• Assuming every QDF must have exactly one task, no exception handling, no state, no behavioral change, or no future evolution.