> For the complete documentation index, see [llms.txt](https://whitepaper.litho.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://whitepaper.litho.ai/docs/governance/rfc-template.md).

# RFC:

## Summary

One paragraph (≤ 5 sentences) describing the proposal as if you were pitching it to a colleague at the whiteboard. A reader who only reads this section should understand **what** and **why**, but not necessarily **how**.

## Motivation

Why does this change need to happen? What problem does it solve? Include:

* The status quo and its failure mode (with a specific incident, metric, or pain point — not a hypothetical).
* Who is affected (users, validators, dev infra, partners).
* The cost of inaction.

## Goals & Non-Goals

**Goals**

* Concrete, measurable outcomes this RFC commits to delivering.

**Non-Goals**

* Adjacent problems intentionally excluded from this RFC. Naming them prevents scope creep in review.

## Detailed Design

The body of the RFC. Required sub-sections:

### Architecture

Component diagram (mermaid or link to drawio). Identify new components, modified components, deleted components.

### Data Model / Schema Changes

* Tables, columns, indexes added/changed/removed.
* Migration strategy (online vs offline; backfill plan).
* Backwards compatibility.

### API / Interface Changes

* New endpoints, deprecated endpoints, breaking changes.
* SDK impact.
* Versioning approach.

### Operational Considerations

* New runtime dependencies (services, env vars, secrets).
* Resource impact (CPU, memory, storage, network).
* Observability hooks (metrics, traces, logs added).
* Failure modes and recovery.

### Security & Privacy

* Threat model deltas.
* New attack surfaces.
* Compliance impact (audit trail, data residency, PII).

## Alternatives Considered

For each alternative: one sentence describing it, then one sentence on why it was rejected. Reviewers will ask if missing — pre-empt by listing 2–3.

## Drawbacks

Why might this be a bad idea? Be honest. Reviewers trust RFCs more when authors acknowledge real tradeoffs.

## Rollout Plan

* Feature flag (default off → canary → 100%)? Direct release?
* Migration triggers and rollback criteria.
* Environments: devnet → staging → mainnet timeline.
* Owner for each phase.

## Unresolved Questions

Open questions that should be resolved **before** acceptance, not deferred to implementation. Each question gets a checkbox.

* [ ] Question 1
* [ ] Question 2

## Success Metrics

How will we know this worked, 30 days after rollout? Concrete metric + threshold per goal listed above.

## References

* Linked tickets, prior RFCs, external standards (EIPs, RFCs), papers.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://whitepaper.litho.ai/docs/governance/rfc-template.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.