Pilar 1 — Fideicomiso de Datos

La tesis. Construir el fideicomiso de datos de la región: una infraestructura de contribución donde instituciones, empresas y personas aportan datos bajo consentimiento granular y revocable, reciben un recibo de procedencia verificable, y se convierten en partes interesadas de primera clase. Derechos, no propiedad. Compensación inmediata en reputación, no promesas diferidas.

Este es el primer pilar del ciclo de los cuatro pilares: el corpus con procedencia es el único activo que hace posible un modelo soberano que nadie más puede replicar.

Por qué un fideicomiso y no una compra de datos

Comprar o raspar datos produce un corpus sin consentimiento, sin licencia clara y sin nadie invertido en su calidad. Un fideicomiso invierte la relación: el aportante es parte interesada, no proveedor. Recibe un recibo verificable en el acto, ve exactamente por qué su contribución valió lo que valió, y conserva el derecho a revocar. El activo que crece no es una tabla — es una red de contribuyentes con incentivo a que los datos sean buenos.

Cómo funciona /contribuir, de punta a punta

La superficie en vivo es /contribuir. El formulario del cliente (src/routes/contribuir.tsx) envía la promesa a la función POST /api/contribute, un transporte delgado sobre un núcleo puro y probado con tests (server/trust/ledger.ts). El flujo:

1. Validación con puerta de consentimiento

validateContribution() normaliza el cuerpo no confiable y rechaza toda promesa sin consentimiento explícito: si consent !== true, la contribución no se crea. También valida el email, exige un título y una descripción del conjunto de datos, y filtra las geografías contra el conjunto canónico de ISO3 de la región — un ledger de procedencia no admite códigos de país basura.

2. Puntuación con una rúbrica transparente

scoreContribution() asigna puntos con una rúbrica determinista y explicada — no un Shapley opaco (su costo combinatorio se descartó al lanzar). Los puntos se descomponen en: base, cobertura geográfica, amplitud de dimensiones, apertura de la licencia, y modo de privacidad. La descomposición viaja en el recibo, así el contribuyente ve exactamente por qué ganó lo que ganó.

La privacidad se premia, no se penaliza

Una contribución que preserva la privacidad (sala limpia o cómputo privado) desbloquea datos que de otro modo no podrían compartirse — por eso se recompensa a la par de los datos crudos abiertos, no por debajo. Es el principio de "computar sin poseer": el valor sin la exposición.

3. Recibo de procedencia firmado, listo para cadena

makeReceipt() emite un Receipt firmado. Sus propiedades verificables:

• El email nunca se almacena. El registro público lleva un contributor_id seudónimo — un hash salado del email. El mismo email produce el mismo id, pero el email crudo no es recuperable ni entra jamás al ledger persistente.
• El recibo es reproducible. El receipt_hash es un SHA-256 sobre el cuerpo canónico (claves ordenadas recursivamente con stableStringify), así que el mismo valor lógico siempre produce el mismo digest. Cualquiera puede recomputar el hash desde las entradas y verificarlo.
• Listo para cadena por construcción. El esquema mapea 1:1 a una atestación on-chain futura: contributor_id, contribution_id y receipt_hash son las columnas de esa atestación, y chain_anchor es la ranura reservada para el hash de transacción cuando llegue la liquidación on-chain (fase posterior). Hoy: chain_ready: true, chain_anchor: null — listo fuera de cadena.

4. Registro append-only y honestidad cuando no está configurado

El ledger es append-only: server/trust/store.ts hace RPUSH a Upstash Redis vía REST. Un recibo nunca se muta. Si Upstash no está configurado, la función es honesta: devuelve el recibo con persisted: false en vez de fingir persistencia.

5. Revocación por tombstone

El consentimiento se prometió revocable; api/revoke.ts es el mecanismo. makeRevocation() escribe un tombstone append-only que computeStats resta al momento de leer — el recibo original permanece en el ledger para siempre (listo para cadena, nunca mutado), pero la contribución queda excluida de los agregados y de la lista pública. La propiedad se prueba recomputando el contributor_id salado desde el email (verifyRevocation): como el email crudo nunca se guardó, solo quien controla ese email puede probar control de la contribución.

La puerta de licencia: solo-cita nunca se vuelve valor

Este es el gate estructural que deja fluir datos aportados al corpus sin violar su licencia (server/trust/license-gate.ts). Espeja la puerta de LicensePosture del registro de fuentes: una contribución cuya licencia prohíbe la redistribución solo puede volverse una referencia de cita, jamás un valor de indicador horneado.

Licencia	Acción en el corpus	Qué permite
open / cc-by / share-alike	indicator	Los valores pueden hornearse en el corpus y la API pública.
non-commercial	aggregates_only	Solo agregados derivados; nunca republicación fila a fila.
cite-only	citation_only	Solo referencia de cita; jamás un valor horneado.

gateViolation() es una regla de compilación: scripts/bake-contributions.ts se niega a publicar valores para datos de solo-cita, y al proyectar una contribución solo-cita a su forma pública, sus geografías y dimensiones se vacían a [] — no se republica cobertura alguna. El recibo estampa la postura (corpus_posture) para que el contribuyente vea de antemano en qué puede convertirse su dato.

Derechos, no propiedad — y el anclaje CARE / LGPD

El marco es derechos, no propiedad: el contribuyente no "vende" un activo, retiene derechos sobre su uso — consentimiento con propósito acotado, revocable. Los datos etiquetados como indígenas llevan una bandera explícita de autoridad-para-controlar, siguiendo los principios CARE (Collective Benefit, Authority to Control, Responsibility, Ethics). El manejo del email — usado solo para la confirmación fuera de banda, nunca persistido — sigue la lógica de minimización de datos de la LGPD brasileña y marcos afines de la región, no una plantilla importada.

Qué está en vivo hoy vs. por fases

	Estado
Contribución con puerta de consentimiento	En vivo — /contribuir
Recibo firmado + hash reproducible	En vivo
Ledger append-only + revocación por tombstone	En vivo (Upstash; honesto si no está configurado)
Puerta de licencia (solo-cita nunca es valor)	En vivo (regla de build)
Rúbrica de puntos transparente	En vivo
Custodia por un fideicomisario independiente	Por fase — a largo plazo la administración sale del operador
Niveles de privacidad / salas limpias operativas	Por fase — el esquema ya los modela; la ejecución llega después
Liquidación on-chain	Por fase — esquema listo (chain_anchor reservado); sin cadena aún

Superficies relacionadas

• /contribuir — el formulario de contribución y el registro público de recibos.
• /datos-abiertos — el corpus abierto con su licencia declarada.
• /linaje — el linaje de procedencia de las cifras.
• /confianza — las insignias de confianza y la trazabilidad.

Sigue el ciclo hacia el Pilar 2 — Modelo Soberano, el modelo que este corpus hace posible.