---
title: <Feature Name>
feature_id: <feature-id>
owner: <Product Manager>
status: draft
target_release: TBD
created: <YYYY-MM-DD>
last_updated: <YYYY-MM-DD>
# Optional:
# JIRA:
#   - PORT-567
---

# <Feature Name>

> Use the unnumbered `##` headings below as written. If a section is intentionally incomplete in `draft`, keep the heading and state what is still needed.

## Executive Summary

Summarize the feature in 3 to 5 sentences.

Cover:

- what capability is being introduced
- which personas benefit, preferably by referencing `PER-*` IDs from `shared/personas.md`
- why it matters now

## Press Release

Write this as a real press release for a launched feature, not as a short future-state paragraph.

Recommended structure:

- launch headline
- one-line subhead
- dateline and announcement paragraph
- supporting executive or customer quote
- `About <Feature>` section describing key capabilities
- `Availability` section

Keep the emphasis on customer value and outcomes, but include enough concrete capability detail that the release reads like a believable launch artifact.

## FAQ

Answer the key stakeholder or customer questions.

### What problem does this solve?

Describe the current limitations or pain points.

### Why now?

Explain why this capability matters at this time.

Typical drivers:

- customer demand
- migration enablement
- operational limitations
- competitive parity

### Why this approach?

Explain why the proposed solution is preferable to alternatives.

### What is out of scope?

Clarify boundaries to avoid scope creep.

## Jobs to Be Done

Use the structure:

```text
#### JTBD-001

> When <actor>, <trigger or situation>, they want to <goal>, so they can <outcome>.

<Optional 1-2 sentence narrative expanding on the context or pain point.>
```

Keep these focused on user progress, not system behavior.

## Problem and Context

Describe the current situation in more detail.

Useful content:

- how customers solve this today
- migration or integration challenges
- operational limitations
- ecosystem context
- representative examples, if helpful

## Goals and Non-Goals

### Goals

Use stable identifiers.

Example:

- **G-001**: Enable reliable event emission using the outbox pattern.
- **G-002**: Support column-based topic dispatch.
- **G-003**: Allow pass-through payload delivery.

### Non-Goals

Document what the feature will not attempt to solve.

Example:

- **NG-001**: Arbitrary event transformation is out of scope for this release.
- **NG-002**: General message processing pipelines remain a separate feature area.
- **NG-003**: Downstream system orchestration is explicitly excluded from scope.

## System Invariants

List guarantees that must remain true.

When possible, reference relevant shared invariants from `shared/system-invariants.md` and add feature-local invariants only where needed.

Example:

```text
#### INV-001: <Invariant Name>

<One sentence stating the system property that must always hold. Use "must always" or "must never" framing.>

Extends: [INV-GLOBAL-001](../../shared/system-invariants.md#inv-global-001-...)
```

## User / Operator Scenarios

Describe concrete workflows that illustrate system behavior. If scenarios are maintained in a separate file, link to `Scenarios.md` here and summarize the areas it covers.

Example stub:

```markdown
See [Scenarios.md](./Scenarios.md) for full scenario definitions.

Key scenario areas to cover:
- Success path: <brief description>
- Failure path: <brief description>
- Rollout or migration path: <brief description>
```

## Functional Requirements

Each functional requirement should be atomic, testable, and easy to scan.

Use this block format:

```text
#### FR-001: <Requirement Name>

Priority: P0 | P1 | P2
Supports: JTBD-001 <!-- add SCN refs after scenario-seeder runs -->

<One or two sentences describing observable behavior. Use "The system shall" or "The feature must" framing.>

**Acceptance Criteria:**
- Given <precondition>, when <trigger>, then <observable outcome>.
- Given <precondition>, when <edge case trigger>, then <expected system behavior>.
```

Each `FR-*` should map to at least one scenario or explicitly say why scenario coverage is deferred.

## Non-Functional Requirements

Use requirement-style blocks instead of a single summary table. Reference shared requirements where applicable instead of restating common policy.

When observability is relevant, state whether RED, USE, both, or neither applies to the feature surface, cite the relevant shared `OBS-*` IDs, and list concrete metrics only when they are feature-specific.

Common shared references:

- `shared/security-requirements.md`
- `shared/observability-requirements.md`
- `shared/compatibility-guidelines.md`

Use this block format:

```text
#### NFR-001: <Requirement Name>

Category: performance | security | compatibility | observability | reliability | operability
Priority: P0 | P1 | P2
Shared References: [SEC-001](../../shared/security-requirements.md#sec-001-...), [OBS-001](../../shared/observability-requirements.md#obs-001-...)

<One sentence stating the non-functional requirement. Include a measurable threshold where possible.>

**Acceptance Criteria:**
- Given <conditions>, the system must <measurable outcome>.
```

## Success Metrics

Define how success will be measured after launch.

| Metric | Target |
|---|---|
| Adoption | Used by target customers |
| Performance | No regression vs baseline |
| Operational Complexity | Reduced manual intervention |

Metrics should align with the jobs being solved.

## Risks

Document potential technical or operational risks.

Use this block format:

```text
#### R-001: <Risk title>

Priority: P0 | P1 | P2
<One sentence describing the risk and its potential impact.>
Mitigation: <One sentence describing how to reduce or monitor this risk.>
```

## Open Questions

Document unresolved issues as section entries rather than `Q-*` IDs.

Example:

- What recovery SLO should this feature commit to in its acceptance criteria?
- Is automatic failover in scope for this release, or explicitly deferred?

## References

Optional supporting material:

- related design documents
- prior art
- research links
- upstream or downstream dependencies
- additional ticket references when relevant