Vercy · perfil aditivo
11 campos para añadir a la memoria que ya usa.
El perfil no sustituye un almacén de memoria. Nombra los campos que los benchmarks encontraron portantes y dice dónde va cada uno en los almacenes que la gente ya ejecuta.
Por qué un perfil y no un formato
El benchmark colaborativo se propuso comprobar si la gobernanza pertenece dentro del registro de memoria o en una capa al lado. No halló diferencia: los campos dentro del registro obtuvieron 95,2%, el mismo grafo con un catálogo de gobernanza aparte 93,5%, y un wiki de equipo con los mismos hechos en prosa 96,8%, con todas las comparaciones por pares en p = 1,00. Dónde se aloja esa información no importa.
Lo que sí importó fue que exista. Añadir gobernanza a un grafo bitemporal lo llevó del 77,4% al 93,5%, p = 0,039. Así que lo útil de publicar no es otro almacén ni otra serialización, sino el conjunto de campos, expresado de modo que pueda añadirse a un grafo, una memoria vectorial, un catálogo, un wiki o una tabla sin mover ningún dato.
Los campos
Cada campo aparece con la capacidad que sostiene y la diferencia medida entre tenerlo y no tenerlo, leída del resultado publicado del estudio que lo midió. PDB es el benchmark de dimensión personal, CMB el de memoria colaborativa.
| Campo | Nivel | Requisito | Qué es | Medido sin → con |
|---|---|---|---|---|
| record_id | 1 | MUST | Un identificador estable del propio registro, corto para poder escribirse a mano. | 0,0% → 100,0% (CMB) |
| valid_from | 1 | MUST | La fecha desde la que la afirmación fue cierta. No la fecha en que se capturó. | 0,0% → 100,0% (PDB) |
| valid_to | 1 | MUST | La fecha tras la cual dejó de ser cierta. El campo debe estar presente; null significa que sigue vigente. | 20,0% → 100,0% (PDB) |
| source | 2 | MUST | De dónde procede la afirmación, como identificador que puede seguirse. | 33,3% → 100,0% (PDB) |
| concept_owner | 2 | MUST | La única parte responsable de lo que significa el concepto. Una por concepto. | 80,0% → 100,0% (CMB) |
| owner_role | 2 | SHOULD | El rol responsable dentro de esa parte, para que una petición llegue a una persona. | 68,8% → 100,0% (CMB) |
| conflict_policy | 2 | MUST | Una regla, enunciada una vez por almacén, para elegir entre registros que cubren la misma fecha y discrepan. | 33,3% → 100,0% (CMB) |
| applies_to | 2 | MUST en todo registro que enuncie una regla | Las clases de pregunta que la regla gobierna. Una regla sin alcance declarado gobierna en silencio más de lo que su autor quiso. | 58,3% → 70,8% (SGB) |
| does_not_apply_to | 2 | MUST en todo registro que enuncie una regla | Las clases de pregunta que la regla explícitamente no gobierna. Se escribe aparte porque el lector no puede inferir la negación de la afirmación. | 79,2% → 83,3% (SGB) |
| release_to | 3 | MUST si algún registro está restringido | Las partes autorizadas a leer este registro. La ausencia del campo no es permiso. | 59,1% → 100,0%; filtraciones críticas 2 → 0 (CMB) |
| supersedes | 3 | SHOULD | El identificador del registro que este sustituye, para que una actualización nunca deba expresarse editando la historia. | 0,0% → 66,7% (PDB) |
| expected_concepts | - | EXPERIMENTAL | Un registro de los conceptos que el almacén debe contener, para que un concepto ausente por completo sea detectable. Sin probar. | 33,3% → 100,0% (R5) |
Tres niveles
Los niveles se ordenan por lo que cada uno desbloquea, de modo que un almacén puede adoptar el perfil por etapas y saber qué ha ganado en cada paso.
Responde preguntas sobre cualquier fecha y permite que una actualización nombre lo que sustituye.
Resuelve la discrepancia por regla y no por conjetura, y dirige una petición de cambio a la parte responsable.
Decide qué puede cruzar una frontera sin filtrar ni negar de más.
Dónde va cada campo
Cinco formas de destino más la nativa. Una celda en ámbar es un campo para el que el destino no tiene sitio, y la celda dice cómo añadirlo. Todo lo demás ya está allí con otro nombre.
| Campo | Grafo bitemporal | Memoria vectorial | Catálogo de datos | Wiki o documentos | Tabla relacional | Dimension de Vercy |
|---|---|---|---|---|---|---|
| record_id | edge uuid | memory id | term or asset identifier | a short tag written in the line, for example [D-102] | primary key | id |
| valid_from | valid_at | add: metadata field, distinct from the created-at timestamp | add: usually only the asset has versions, the statement does not | stated in the sentence | date column | valid_from |
| valid_to | invalid_at | add: metadata field | add: same | stated in the sentence | nullable date column | valid_to |
| source | the episodic node the edge was extracted from | metadata field | lineage link to the source asset | named in the sentence | foreign key to a source table | source |
| concept_owner | add: OWNED_BY edge from the entity to a party node | add: metadata field | owner field, native | a page listing who owns what | foreign key to a party table | concept_owner |
| owner_role | add: role attribute on that OWNED_BY edge | add: metadata field | steward or accountable role, native | the role named on that page | column on the party table | owner_role |
| conflict_policy | add: one graph-level property, or a single policy node | add: one pinned memory, or application configuration | add: a policy document linked from the glossary | a page stating how disagreements are settled | one row in a policy table, referenced by the store | conflict_policy |
| applies_to | add: attribute on the rule edge, or SCOPES edges to entity classes | add: metadata list on the memory holding the rule | policy scope, native in most catalogues | the sentence says which questions the rule governs | join table of rule to question class | applies_to |
| does_not_apply_to | add: EXCLUDES edges from the rule edge | add: metadata list, kept separate from applies_to | add: catalogues usually state inclusion only | a second sentence saying what it does not govern | the same join table with an excluded flag | does_not_apply_to |
| release_to | add: VISIBLE_TO edges, or a list attribute on the fact edge | add: metadata list, applied as a retrieval filter | classification and purpose policies, native | stated in the line that holds the restricted statement | join table of record to party | release_to |
| supersedes | add: SUPERSEDES edge between fact edges | add: metadata field holding the prior memory id | term version history, native | the tag of the superseded line, named in the new line | self-referencing foreign key | supersedes |
| expected_concepts | add: entity nodes marked as expected but unpopulated | add: a separate register, not a memory | add: a list of required terms | a checklist page | a table of required concepts | not yet in the specification |
Las celdas usan el vocabulario de cada sistema de destino y se dejan en inglés en todos los idiomas, para que esta tabla, profile.yaml y mappings.csv digan lo mismo. La columna del wiki no es un recurso de última hora: en el benchmark colaborativo un wiki que llevaba estos campos en frases corrientes obtuvo un 96,8%, el mejor de todas las representaciones probadas.
Cuatro cosas que se hacen mal al implementarlo
- El perfil es aditivo. Nada de esto pide mover datos ni cambiar de almacén.
- valid_from no es la marca de tiempo que su almacén ya tiene. El momento de captura y el de validez son distintos, y de esa diferencia depende todo resultado histórico de estos benchmarks.
- Un release_to ausente no es permiso. Donde falta el campo, la lectura segura es que el registro no puede entregarse.
- Una política de conflicto por almacén, enunciada una vez. Repetirla en cada registro invita a que dos registros discrepen sobre cómo se resuelve la discrepancia.
En qué se apoya esto
Tres benchmarks, 1926 llamadas al modelo, una familia de modelos, herramientas desactivadas y un mundo redactado por estudio. Las magnitudes anteriores proceden de razonar sobre registros presentes en el contexto; la recuperación, el ranking y la ingesta quedaron fuera, y son lo que varios productos de memoria consideran su aportación principal. El campo expected_concepts es una hipótesis derivada de un punto ciego medido, no un resultado: ningún estudio lo ha probado. Cada cifra remite a una ejecución bruta publicada.
Cómo registrar un cambio
Ambos benchmarks produjeron el valor nuevo correcto en todos los escenarios y la fecha de frontera equivocada en entre un tercio y un quinto de ellos. La solución no es un mejor prompt sino una operación más estrecha: se escribe un registro nuevo, se le da la fecha en que empieza la nueva afirmación, se nombra el registro que sustituye y no se toca el registro sustituido.
superseded record, left untouched:
{
"record_id": "D-802",
"concept": "data_retention",
"value": "customer records are kept for five years after the contract ends",
"valid_from": "2026-06-01",
"valid_to": null,
"source": "LEG-POL-04",
"concept_owner": "legal",
"supersedes": "D-801"
}
new record:
{
"record_id": "D-806",
"concept": "data_retention",
"value": "customer records are kept for three years after the contract ends",
"valid_from": "2026-10-01",
"valid_to": null,
"source": "LEG-POL-06",
"concept_owner": "legal",
"supersedes": "D-802"
}
El final de un intervalo sustituido se deriva al leer, nunca se escribe: un registro está vigente en una fecha cuando la cubre y nada que lo sustituya empezó en esa fecha o antes. Editar el registro antiguo, o calcular su fecha final a mano, es exactamente donde ocurrieron los errores medidos.
El único campo que era una hipótesis, y su prueba
expected_concepts se publicó como propuesta derivada de un punto ciego medido: en el benchmark de anclaje semántico, una definición ausente por completo del catálogo fue el único hueco que ni la prosa ni la estructura encontraron nunca. Un registro que nombra los conceptos que un almacén debe contener convierte esa ausencia en algo señalable. Al publicarse no estaba probado. Ahora sí: 60 llamadas sobre el mismo catálogo deficiente con y sin el registro.
| Medida | Sin el registro | Con él |
|---|---|---|
| detectar el concepto ausente por completo | 33,3% | 100,0% |
| detectar cualquiera de los seis huecos plantados | 83,3% | 100,0% |
| falsas alarmas en cuatro preguntas sin hueco | 8,3% | 8,3% |
El campo funciona en el caso para el que se diseñó, y el control que importaba se mantuvo: un registro que hiciera inventar huecos habría sido peor que ninguno, y las falsas alarmas no se movieron. Pero solo dos de los seis huecos cambiaron, así que la prueba de signos exacta sobre la familia da p = 0,5. Un experimento pequeño no crea un requisito, de modo que el campo sigue siendo EXPERIMENTAL. La ejecución bruta se publica junto al perfil.
Pagar menos contexto por los mismos campos
El dimension fue el contexto más largo en los dos estudios posteriores y empató en exactitud, así que el perfil no debería costar el doble de contexto para decir lo mismo. Un orden de campos fijo y una línea por registro elimina la mayor parte de ese coste. Las cifras siguientes se miden al compilar sobre el almacén de referencia publicado, no se afirman.
| Serialización | Caracteres | Ahorro |
|---|---|---|
| un objeto JSON por línea | 6.064 | - |
| forma de línea compacta | 1.860 | 69,3% |
# record_id|valid_from|valid_to|source|concept_owner|owner_role|supersedes|release_to|value D-101|2025-01-01|2026-03-31|FIN-POL-04|finance|Head of Finance
La otra mitad del ahorro es la selección. En la pista de ensamblado del benchmark de dimensión personal, un agente al que se pidió elegir los registros que la pregunta necesita recuperó todos los necesarios, eligió 1,2 registros de 41 y recortó el contexto entregado de 10.332 a 473 caracteres sin cambio medible en la exactitud, p = 0,34. La reducción está medida; una ganancia de exactitud no lo está y no debe afirmarse.
Comprobar un almacén frente a los niveles
El comprobador acepta un array JSON o un registro por línea, y un mapa de sus nombres de campo a los roles del perfil. Informa del nivel más alto que el almacén satisface y nombra los registros que fallaron cada requisito. Sale con código distinto de cero por debajo del nivel 1, así que encaja en una compilación.
python check.py store.jsonl python check.py store.jsonl --map record_id=uuid,valid_from=valid_at,valid_to=invalid_at,source=episode
Junto a él se publican dos fixtures. El almacén de referencia alcanza el nivel 3. Los mismos registros como aristas de hecho bitemporales alcanzan el nivel 1 e informan exactamente de lo que el benchmark colaborativo encontró que faltaba: sin propietario del concepto y sin política de conflicto.