stakeholder-brief

You are producing a stakeholder-facing brief for a specific arc or stage of the SRF Online Teachings Portal. Your audience is SRF's Audience Engagement team and organizational leadership — not engineers.

Your Task

Read the project's existing design documentation and synthesize an arc-level proposal that a non-technical SRF staff member can evaluate, approve, or defer. You are NOT exploring a new idea. You are translating existing technical architecture into organizational communication.

Reading Strategy

Read in this order:

1. CLAUDE.md — project rules and conventions (read fully)
2. CONTEXT.md — project background, stakeholders, methodology, open questions (read fully)
3. ROADMAP.md — find the specific arc or stage you're briefing. Read its deliverables and success criteria.
4. features/FEATURES.md — scan the FTR index to identify specs relevant to this arc's deliverables
5. FTR files — read only the FTR files relevant to this arc (use features/{domain}/FTR-NNN-*.md)

PROPOSAL.md Structure

IMPORTANT: You MUST use the Write tool to create a file named PROPOSAL.md in the current working directory. Write early, write often — create the skeleton after initial reading and fill incrementally.

Your session is considered failed if PROPOSAL.md does not exist on disk when you finish.

Required Sections

# Arc [N]: [Name] — Stakeholder Brief

## What This Arc Means for Seekers

[Open with 2-3 concrete seeker stories showing what becomes possible WITH this arc
and what's lost WITHOUT it. Write from the seeker's perspective, not the engineer's.
Example: "A mother in Kolkata searches 'how to teach children about God' at midnight..."
Ground each story in the project's mission: teachings findable at the moment of need.]

## What We Build

[Plain-language summary of what this arc delivers. No jargon. No data types.
No API endpoints. Describe capabilities as a seeker or staff member would experience them.
Group related deliverables into 3-5 themes rather than listing all individually.]

## Why It's Designed This Way

[The key tradeoffs and design decisions behind this arc, explained in terms
SRF leadership would care about: mission alignment, cost, timeline risk, theological
considerations, global equity implications. Reference FTR numbers parenthetically
for engineering drill-down, but explain the reasoning in plain language.]

## What SRF Needs to Decide

[Explicit decision points. Frame as questions SRF must answer before or during
this arc. Pull from CONTEXT.md open questions where relevant. Each decision
should include:
- The question
- Why it matters (consequence of delay or wrong choice)
- The options available
- Any recommendation from the design work]

## What Must Come First

[Dependencies — both technical (prior arcs) and organizational (SRF staffing,
content availability, vendor contracts, theological review). Be honest about
what blocks this arc.]

## Principles This Arc Honors

[Brief mapping to the project's core principles: verbatim fidelity, calm technology,
DELTA compliance, global equity, human review gates, 10-year architecture horizon.
Only mention principles directly relevant to this arc's deliverables.]

## Risks and Mitigations

[2-4 risks specific to this arc. Not generic project risks. What could go wrong
with THIS arc, and what the design does to address it.]