# RFC Process

| Field | Value |
|---|---|
| Document | ONDC-RFC-001 |
| Status | Draft RFC; Not Adopted |
| Updated | 2026-11-03 |
| Project | Skydream Cloud |

## Scope

This document proposes the Request for Comments (RFC) process for ONDC. Project RFC identifiers belong to the Skydream project, independently of the IETF RFC Series.

Changes to the specification should have a durable, readable record of the problem, alternatives, evidence, objections and outcome. Participation should be possible without joining a private chat.

Decision authority, contribution terms and adoption of this process remain open governance decisions.

## Why A Written Proposal Matters

Imagine two applications opening the same file. One preserves a chart it cannot edit. The other removes the chart while saving a small paragraph change. Both may appear to support the document until someone reopens it and discovers the loss. A change to that behavior needs more than a feature announcement: implementers need an agreed contract and examples of what must survive.

An RFC is the place to explain that contract before applications depend on it. It should let a reader understand the problem without having followed a chat or a design meeting. The record should remain useful after the discussion ends: what was chosen, why alternatives were declined, and what evidence is still missing.

This document proposes a process. Its detailed steps are recommendations for adoption, not an already operating governance system. Public repositories, decision authority, maintainership rules and contribution terms still need to be established.

## Which Changes Need An RFC?

| Change | Proposed Route | Reason |
|---|---|---|
| New element, property, default or interpretation | RFC | Independent consumers need the same meaning |
| Profile gains a previously rejected feature | RFC or a bounded amendment with equivalent evidence | An editor's preservation promise changes |
| Archive, asset or encryption boundary changes | RFC with specialist review | Portability and disclosure risks extend beyond rendering |
| Compatibility, migration or release-policy change | RFC | Existing files and support claims are affected |
| Typo correction that leaves meaning unchanged | Small documented correction | A full proposal adds little value |
| Implementation bug fixed to match an existing rule | Normal implementation review with a regression example | The contract stays the same |
| Ambiguous wording resolved in a way that changes behavior | RFC | Calling a change a clarification does not remove its impact |

When classification is uncertain, write down the ambiguity and ask for a bounded review. The size of a code diff is not a reliable measure of semantic impact. A one-word default change can affect every existing file.

## Start With A User And A File

A useful proposal begins with a concrete situation. For example: “A person wants to correct a paragraph in a document containing an unsupported chart. The current editor refuses the file. We want to permit that edit while preserving the chart.” That gives reviewers a problem they can evaluate before choosing a representation.

Include a minimal input file, the requested action, the expected result, and the current failure. For preservation work, name both the content allowed to change and the content that must remain intact. Avoid requiring reviewers to infer behavior from a screenshot.

The proposal should then teach the new interaction in ordinary language. What will the person see? What can they edit? What happens when the application reaches its limit? Only then introduce the detailed model, invariants and edge cases.

## A Working Proposal Template

The following outline is a proposed starting point, not a new document schema:

```text
Title and short identifier
Status, authors, date and related proposals

1. Summary
2. Problem and current behavior
3. Worked user and implementer example
4. Detailed design and invariants
5. Invalid inputs and failure behavior
6. Compatibility, preservation and migration
7. Privacy, security and resource limits
8. Alternatives and costs
9. Fixtures, implementation evidence and documentation
10. Unresolved questions and out-of-scope work
11. Decision record and target publication, when decided
```

The detailed design should be sufficient for another implementer to attempt the same behavior. Explain ordering, defaults, identifier rules and interactions with existing features where relevant. If two plausible readings yield different outputs, include a case that distinguishes them.

Evidence should include valid and invalid examples and a stated oracle: what is compared, and what counts as success? Byte preservation, equal document meaning and equal appearance are different assertions. A proposal should say which one it needs.

## Review As A Sequence Of Decisions

The earlier lifecycle can be made practical with the following checkpoints:

1. **Draft:** an author records the problem, scope and initial examples. Missing evidence is labeled rather than hidden.
2. **Review:** participants challenge assumptions, test the examples and propose alternatives. The author keeps the main text current and summarizes unresolved objections.
3. **Evidence:** a prototype or headless fixture set checks the proposed behavior. Where implementation must follow acceptance, the proposal identifies an explicit release gate instead of claiming the gate has passed.
4. **Decision:** the authorized decision-maker, once that role is established, records acceptance, requested revision, deferral, withdrawal or rejection with reasons.
5. **Implementation:** accepted work is tracked separately. Acceptance does not mean an application can read or edit the feature yet.
6. **Publication:** the change enters a named draft/profile only when the required implementation, fixtures and documentation are ready. Publication records remaining limits.

Deferral should say what information would justify reopening the proposal. Rejection should retain the rationale and alternatives, so the next author does not need to repeat the entire investigation. Withdrawal should preserve the discussion while making clear that the author is no longer pursuing the draft.

Before adoption, the project must decide how review deadlines work, how conflicts of interest are handled, how maintainers are appointed and replaced, and how a decision can be appealed. This draft does not invent those authorities or promise a vote.

## Worked Example: Preserving A Chart

The chart example is hypothetical. The current editor rejects unsupported objects; it has no generic preservation engine. A proposal to change that would need to answer at least these questions:

- Can the object be represented in a stable, explicitly declared envelope?
- Which original bytes, assets and relationships must be retained?
- Can text edits move its anchor without invalidating its meaning?
- What information can the application safely show about an object it cannot interpret?
- Is a read-only document the appropriate fallback when any required dependency is unsupported?
- How will a subsequent application confirm that the chart and its placement survived?

One alternative is the existing refusal policy. Another is a read-only viewer. A third is limited editing with verified opaque preservation. The last option offers more convenience but creates a much larger preservation contract. The RFC must explain those costs and include examples where preservation is impossible and editing is refused.

A fixture should show the original document, a permitted paragraph edit and expected unchanged chart resources. Negative cases should cover missing assets, broken references and edits that remove the chart's anchor. A clean XML parse alone would not be enough evidence.

## Keeping Decisions Useful

The proposal should link the eventual reference text, schemas, fixtures, compatibility notes and implementation work. Once a decision is published, preserve its historical reasoning. Small editorial corrections can be recorded in place; a substantial reversal should have a new proposal that explains what it supersedes.

Keep current documentation current. An old accepted RFC is a record of a decision, not a substitute for maintained instructions about today's format or editor profile. If implementation reveals a new semantic problem, return that problem to review instead of silently changing the meaning in code.

## Participation And Sensitive Reports

GitHub is the intended public review channel, but repositories and contribution terms have not been announced. For now, use hello@skydreamcloud.com for feedback. A useful report describes the expected behavior, actual behavior and the smallest safe example. Do not send private working documents when a synthetic sample can demonstrate the issue.

Security-sensitive findings need a private reporting path before public discussion of exploit details. The project still needs to publish that policy. A public RFC is appropriate for the eventual design and compatibility consequences once disclosure is safe.

## Costs, Alternatives And Open Questions

Written review takes time. It can discourage small contributions if every correction requires a long proposal. The bounded-correction route above is meant to keep that cost proportional. Conversely, discussion only in issues or chat can leave implementers without a stable decision record. Both failure modes deserve attention.

Open questions include the decision authority, review duration, amendment threshold, specification/code licenses, patent and contribution terms, appeals, and the evidence needed from independent implementations. These must be settled publicly before this process can be described as adopted.

## Editorial References

- [Rust RFC template](https://github.com/rust-lang/rfcs/blob/main/0000-template.md): a reference for explaining a problem through examples before presenting technical detail and alternatives.
- [Rust RFC process](https://rust-lang.github.io/rfcs/): a reference for distinguishing design acceptance from implementation and maintained documentation.
- [CommonMark 0.31.2](https://spec.commonmark.org/0.31.2/), §§1.2–1.3: a reference for using specific cases to resolve ambiguity.
- [Versioning and Conformance](versions-and-compatibility.md): proposed publication and support requirements.

References accessed 2026-11-03. The structure is informed by these projects; their governance and license terms are not adopted by this draft.

## Feedback

Send comments to hello@skydreamcloud.com until the public channels open. This document can be revised as the contribution and governance model is developed.