# [Pattern name]

**ID:** NR-[000] | **Version:** 0.1.0 | **Status:** Reference / illustrative

## Intent
One paragraph stating the problem and result.

## Context and forces
What business and technical constraints make this relevant?

## Architectural view
Include editable `diagram.dot` or `diagram.mmd`, plus SVG/PNG exports.

## Responsibilities and invariants
- Which capability owns what?
- What must never be violated?
- What is probabilistic and what is deterministic?
- Where is state persisted?

## Contracts, flows and failure
- Inputs/outputs, schemas and security boundaries:
- Delivery semantics and ordering:
- Error handling, rollback, idempotency and audit:
- Minimum observability:

## When to use / not use
- Use when:
- Do not use when:

## Trade-offs
- Alternative and what is lost / gained:

## Review checklist
- [ ] Business capability owner identified
- [ ] Security and trust boundary identified
- [ ] State change and recovery described
- [ ] Measurable quality attributes set
- [ ] Design alternatives evaluated
- [ ] Release/operations ownership established

## Attribution and changes
Adapted from nishtnr’s Architecture Library (CC BY 4.0), link to the original, record modifications.