Le format de connaissances ouvert de Google ajoute cinq signaux de confiance

Google a annoncé une mise à jour de l’Open Knowledge Format (OKF), version 0.2. La nouvelle version ajoute cinq fonctionnalités liées à la confiance qu’un « consommateur » de l’OKF peut utiliser pour vérifier cinq aspects des bundles OKF.

Les cinq signaux de confiance et leurs champs OKF et types de concept associés sont :

  1. Provenance (champ : sources)
  2. Confiance (champs : générés, vérifiés)
  3. Fraîcheur (champ : stale_after)
  4. Cycle de vie : (champ : statut)
  5. Attestation (nouveau type de concept : calcul attesté)

L’annonce positionne ces cinq signaux comme répondant à cinq questions sur l’offre groupée OKF afin d’établir la confiance.

Les cinq questions :

  1. « De quoi a-t-il été créé ? (provenance)
  2. Dans quelle mesure dois-je lui faire confiance ? (confiance)
  3. Est-ce toujours vrai ? (fraîcheur)
  4. Est-ce la version actuelle ? (cycle de vie)
  5. Ce numéro a-t-il été produit comme nous l’avions prévu ? (attestation) »

Provenance

Google introduit un nouveau champ « sources » qui enregistre la provenance des informations contenues dans un concept. Cela permet aux consommateurs d’identifier les sources originales utilisées pour le créer. Cela fournit des informations sources que les consommateurs peuvent utiliser pour évaluer la fiabilité d’un concept, en répondant à la question « De quoi a-t-il été créé ? ».

Voici l’exemple de Google du champ sources :

sources:
- id: warehouse-schema
resource: https://wiki.acme.internal/data/warehouse/schemas/sales
title: Acme Retail warehouse schema — sales dataset
author: team:data-platform
usage_count: 1240
last_modified: 2026-06-15
- id: revenue-policy
resource: policies/revenue-recognition.md
title: Revenue Recognition Policy (FY2026)
author: human:jsmith@acme
last_modified: 2026-06-15

Google explique ce que tout cela signifie :

« Le nouveau champ Sources enregistre les matériaux dont dérive un concept : un document externe, un chemin relatif au bundle ou même un descripteur de portée comme « toutes les requêtes du projet X ». Dans le même temps, une entrée peut véhiculer des signaux de crédibilité objectifs : author, usage_count, last_modified.

Le choix délibéré ici est ce que nous n’avons pas ajouté. OKF enregistre les signaux, pas un score de crédibilité. Une partition est subjective, n’est pas transmise aux consommateurs et devient obsolète au moment où elle est écrite.

Au lieu de cela, la crédibilité est déduite des signaux par celui qui consomme (et peut être évaluée dynamiquement par le consommateur, s’il le souhaite), de la même manière que vous feriez plus confiance à une source largement utilisée, récemment mise à jour et rédigée avec autorité qu’à une source anonyme. Et lorsque le corps cite une source spécifique, il le fait avec une note de bas de page ordinaire liée à l’identifiant de la source ([^export-schema]), donc l’attribution se fait par revendication au lieu d’une liste pendante en bas.

Confiance : champs générés et vérifiés

La partie suivante des signaux de confiance sont les champs générés et vérifiés.

Le champ « généré » enregistre qui a créé un concept, tandis que le champ « vérifié » enregistre qui l’a confirmé de manière indépendante. Un consommateur (tel qu’un agent IA, un LLM ou une application) peut utiliser les informations de vérification pour filtrer les concepts selon qu’ils sont non vérifiés, confirmés par une machine ou examinés par un humain.

Voici l’exemple des champs Généré et Vérifié utilisés :

type: Metric
title: Revenue
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }
verified:
- { by: human:jsmith@acme, at: 2026-07-01T09:00:00Z }

Fraîcheur et cycle de vie : champs status et stale_after

Le champ d’état indique à quelle partie du cycle de vie se trouve un concept afin qu’un consommateur puisse identifier s’il est en projet, actuel ou obsolète (obsolète). Il indique si un concept est une ébauche, stable ou obsolète.

Le champ stale_after précise la date après laquelle le concept doit être re-vérifié avant d’être utilisé. Les consommateurs peuvent utiliser ces champs pour identifier les concepts qui doivent être revérifiés ou pour exclure les concepts obsolètes des nouveaux travaux tout en les préservant à des fins de référence historique.

Voici un exemple d’utilisation :

type: Metric
title: Gross Margin (legacy, pre-FY2026)
status: deprecated

Calcul attesté : pour vérifier les calculs

Le calcul attesté n’est pas un champ, c’est un nouveau type. Le calcul attesté définit la manière approuvée de calculer une valeur et fournit un moyen de vérifier que le calcul a été effectué de la manière dont il était censé être calculé.

La description officielle explique :

« La provenance répond à l’origine d’une réclamation. L’attestation répond à une question plus difficile qui compte dès qu’un agent déclare un montant en dollars : ce chiffre a-t-il été produit comme nous l’avons dit, ou l’agent a-t-il improvisé son propre code SQL ?

OKF v0.2 introduit un nouveau type de concept, le calcul attesté. Il ne contient pas seulement ce que signifie une valeur, mais également une manière sanctionnée de la calculer et les moyens de vérifier que la chose sanctionnée a réellement fonctionné.

Voici l’exemple :

---
type: Attested Computation
title: Revenue for a fiscal year
runtime: bigquery
parameters:
- { name: year, type: integer, required: true }
executor:
resource: skills/run-on-bq.md
receipt: [job_id, executed_sql, result]
attester:
resource: attesters/sql_equality.py
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }
verified:
- { by: human:jsmith@acme, at: 2026-07-01T09:00:00Z }
status: stable
stale_after: 2026-12-31
sources:
- id: revenue-policy
resource: policies/revenue-recognition.md
title: Revenue Recognition Policy (FY2026)
author: human:jsmith@acme
last_modified: 2026-06-15
---

# Computation

SELECT
SUM(
CASE
WHEN o.currency = 'USD' THEN o.net_amount
ELSE o.net_amount * fx.rate_to_usd
END
) AS revenue_usd
FROM `acme.sales.orders` AS o
LEFT JOIN `acme.finance.fx_daily_rates` AS fx
ON fx.currency = o.currency
AND fx.rate_date = DATE(o.order_ts)
WHERE o.order_status="delivered"
AND DATE_DIFF(CURRENT_DATE(), DATE(o.order_ts), DAY) >= 30
AND EXTRACT(YEAR FROM o.order_ts) = @year"

Documentation mise à jour au format Open Knowledge

Google a mis à jour le référentiel GitHub pour refléter cette mise à jour et a publié une annonce qui sert d’explication.