Introduction

Every normative statement here is adopted through the RFC process (/rfcs), and changes to it arrive the same way.

§0.1 What the Cabuya Protocol is

Cabuya is an open interoperability protocol for aid applications. It defines:

1. One schema, four transports. A static JSON feed (L2), a read API (L3), a write API (L4) and an MCP surface are projections of the same place record — a static feed is a degenerate read API and vice versa.
2. A discovery mechanism — a manifest at a well-known path plus a PR-reviewed registry (§2).
3. A conformance ladder (L0–L4), measured by a published validator, never self-declared (§1, §8).
4. Normative exclusions that do not move — person-level data never travels; contact values never travel; data enters by publication, never by scraping (§7).

The founding principle, normative where the spec can carry it: «Crecemos juntos: no competimos, nos alimentamos» — feeds exist so apps feed each other.

§0.2 Conventions

The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.

Machine identifiers (field names, place_kind tokens, check ids, level names) are never translated. Human-readable strings in feeds follow §3’s localization rule, with es as the REQUIRED baseline.

§0.3 Document map

Section	Contents
§1	The conformance ladder L0–L4
§2	Manifest, well-known path, the registry
§3	The feed envelope and the place record
§4	Read/write APIs, consumption rules, sync, MCP
§5	Record and place identity
§6	The verification block; threat posture
§7	The lines that don’t move
§8	SemVer, profiles, measured conformance
Appendix A	Non-normative: decision log + the implementability walkthrough

Schemas: manifest.schema.json · place-feed.schema.json — with five worked examples (two valid, three invalid with designed error messages) in examples/.