UW Markdown RFCs
This directory contains the request-for-comments documents that precede any normative change to UW Markdown — the format spec, the protocol spec, the JSON Schemas, the conformance corpus, or the public API of @uwmd/core.
See GOVERNANCE.md for when an RFC is required and how it gets accepted.
Process
- Copy
0000-template.mdtoNNNN-<short-slug>.mdusing the next free number. - Fill in the design, compatibility, conformance, and implementation sections.
- Open a pull request or, in owner-led mode, commit it with the implementation.
- The project owner accepts, requests changes, or rejects the proposal.
- In owner-led mode there is no mandatory waiting period. After collaborative mode activates under
GOVERNANCE.md, a normative RFC remains open for public comment for at least 14 days before acceptance. - Accepted RFCs move to
accepted; after the implementation ships, they move toimplemented. Rejected and superseded RFCs remain as design history. - An RFC whose own deliverable is the decision — it defines no fields and ships no code — is
decidedrather thanaccepted, and that is terminal. See Status values for the full vocabulary and for howdecideddiffers fromaccepted.
Index
| # | Title | Status | Affects |
|---|---|---|---|
| 0001 | Locale negotiation | implemented | format, protocol, core, conformance |
| 0002 | Module signing | implemented | protocol, core, conformance, tooling |
| 0003 | Custom asset-class declarations from modules | implemented | format, protocol, core, conformance, tooling |
| 0004 | Conformance test runner v2 (language-agnostic) | implemented | protocol, core, conformance, tooling |
| 0005 | Stochastic calculations | implemented | protocol, core, conformance |
| 0006 | Hospitality reference module | implemented | core, conformance, tooling |
| 0007 | Sensitivity tables as a calc primitive | implemented | protocol, core, conformance |
| 0008 | Lease-up modeling | implemented | protocol, core, conformance |
| 0009 | _meta v2 sub-object reorganization | implemented | format, protocol, core, conformance |
| 0010 | Signed blocks | implemented | format, protocol, core, conformance, tooling |
| 0011 | Capability tokens for write authorization | implemented | protocol, core, conformance |
| 0013 | Embedding-based corpus retrieval | draft | protocol, core, conformance |
| 0014 | Extensible multi-format interchange | implemented | format, protocol, core, conformance, tooling |
| 0015 | Portfolio and relationship profiles | implemented | format, protocol, core, conformance, tooling |
| 0016 | Signed deterministic verification receipts | implemented | format, protocol, core, conformance, tooling |
| 0017 | .uw.md Lite / .uwx.md Extended source split | implemented | format, protocol, core, conformance, tooling |
| 0018 | Composable document profiles and deal packages | implemented | format, protocol, core, conformance, tooling |
| 0019 | Mixed-use composition as a document shape | implemented | format, protocol, core, conformance, tooling |
| 0020 | Align the format spec and examples with .uwx.md | implemented | format, protocol, conformance, tooling |
| 0021 | Composable UWX documents — externalization, composites, rollup receipts | implemented | format, protocol, core, conformance, tooling |
| 0022 | Market data as an attributable UW document | implemented | format, protocol, core, conformance, tooling |
| 0023 | A numeric model and a single quantization boundary | implemented | protocol, core, conformance, tooling |
| 0024 | Pin the iterative solvers so two engines agree on a root | implemented | protocol, core, conformance |
| 0025 | Scale percent displays by moving the point, not by dividing | implemented | format, core, conformance |
| 0026 | A typed capital stack — tranches, preferred equity, and stack-aware sizing | implemented | format, protocol, core, conformance, tooling |
| 0027 | Declare every asset class's size intensive, once | implemented | format, protocol, core, conformance, tooling |
| 0028 | Make a missing required section a reportable defect | implemented | format, core, conformance |
| 0029 | Make stage requirements class-aware | implemented | format, core, conformance |
| 0030 | Make partial conformance mechanically checkable | implemented | protocol, core, conformance, tooling |
| 0031 | Reconcile the source vocabularies and close the unpoliced-write path | implemented | format, protocol, core, conformance, tooling |
| 0032 | State how _meta.provisional interacts with signing | implemented | protocol |
| 0033 | Scope capital_stack to one point in time | implemented | format |
| 0034 | Calendar-anchored cash flows — dated series, day counts, deterministic xirr/xnpv | implemented | format, protocol, core, conformance |
| 0035 | Distribution waterfall — state-and-verify promote, pref, and catch-up over a dated series | implemented | format, protocol, core, conformance |
| 0036 | IRR-hurdled waterfall tiers — a closed-form boundary, not a nested solve | implemented | format, protocol, core, conformance |
| 0037 | Cross-check resolution over variant maps, and a validation coverage channel | implemented | format, protocol, core, conformance |
| 0038 | Tax basis on stated return metrics | implemented | format, protocol, core, conformance |
| 0039 | Data-center module — the first product module on a module-declared asset class | implemented | core, conformance, tooling |
| 0040 | Variant roles — resolve cross-checks by a declared role, not a key name | implemented | format, protocol, core, conformance |
| 0041 | Explicit period addressing for the standard series | implemented | format, protocol, core, conformance |
| 0042 | Stated period inputs in refinement | implemented | protocol, core |
| 0043 | Contextual Excel period bindings | implemented | protocol, core, tooling |
| 0044 | Project verified lease-up amounts onto explicit cash dates | implemented | protocol, core, conformance, tooling |
| 0045 | Assemble explicitly covered property cash flows | implemented | protocol, core, conformance, tooling |
| 0046 | Document currency identity | implemented | format, protocol, core, conformance |
| 0047 | Property cash-flow input inventory | implemented | core, tooling |
| 0048 | Standalone UW document kit and package examples | implemented | conformance, tooling, documentation |
| 0049 | PostgreSQL JSONB lake adapter boundary | implemented | tooling, documentation |
| 0050 | Preferred equity with a split coupon | implemented | format, protocol, core, conformance |
| 0051 | Distribution waterfall dual-hurdle "any" mode | implemented | format, protocol, core, conformance |
| 0052 | Named exit sale deductions | implemented | protocol, core, conformance |
| 0053 | Tax abatements and reassessment basis | implemented | format, protocol, core, conformance |
| 0054 | Where per-lease economics live (decision) | decided | format, documentation |
| 0055 | Typed commercial lease clauses | implemented | format, protocol, core, conformance |
| 0056 | Typed rate hedges, escrows and the reserves that fund them | implemented | format, protocol, core, conformance |
| 0057 | The renovation draw, and capex that buys an expense reduction | implemented | format, protocol, core, conformance |
| 0058 | Expense recoveries and the CAM true-up | implemented | format, protocol, core, conformance |
| 0059 | Waterfall clawback as a terminal true-up | implemented | format, protocol, core, conformance |
| 0060 | The four tranche-class candidates (decision) | decided | documentation |
| 0061 | Keep protocol version labels synchronized | implemented | protocol, tooling, documentation |
| 0062 | Permit same-day cash-flow rows while refusing ambiguous selectors | accepted | format, protocol, core, conformance |
0012 is an unused number, left as a gap so existing references keep their meaning. RFC 0017 is retroactive: it documents a change that shipped before its RFC was written, and records that process failure rather than hiding it. See its Process failure section.
Status values
This is the authoritative list. An RFC's frontmatter status: must be one of these values, and npm run verify-indexes fails on any other.
- draft — author is still iterating; reviewers may comment but the proposal is not stable.
- active — open for comment; the 14-day minimum applies in collaborative mode.
- accepted — merged with intent to implement, and this RFC itself still promises implementation that has not shipped.
- decided — terminal. The RFC's own deliverable is the architectural or design decision, and it explicitly promises no implementation of its own.
- implemented — the change has shipped in a release; CHANGELOG entry exists.
- rejected — closed without merging the change. RFC stays in the directory.
- superseded — replaced by a later RFC; cross-link both.
- withdrawn — author pulled the proposal.
accepted versus decided
The test is what this RFC promises, not whether any work remains in the area.
A decided RFC may identify implementation that a separate future RFC would have to carry. That deferral does not demote it to accepted, because the deferred work was never this RFC's deliverable — there is nothing here left to ship, so it never becomes implemented.
RFC 0054 is the worked example: it decides where per-lease economics live, states outright that it "defines no fields and implements nothing", types the lease clauses through RFC 0055, and defers the periodic series until a consumer exists. It is decided, not accepted, even though it names future work.
Use accepted when the RFC in hand describes a change that is still owed.
When status changes, edit the RFC's frontmatter and update this index.