Expliquer une décision en utilisant la policy qui existait au moment où elle a été prise

Quand compliance pose une question sur une décision d'il y a 18 mois

Un client a été rejeté il y a 18 mois. Compliance, l'audit interne ou un régulateur pose la question que chaque organisation finit par affronter :

Pourquoi ce client a-t-il été rejeté ?

Le decision log répond avec ce qui s'est passé à la couche opérationnelle :

decision   = REJECTED
rule       = R-182
timestamp  = 2025-02-14T09:12:00Z

L'étape naturelle suivante est de regarder la règle R-182. Mais R-182 a pu être modifiée plusieurs fois depuis 2025-02-14. Et des overrides peuvent avoir été en vigueur à ce moment qui ne sont plus visibles aujourd'hui, ou des overrides peuvent être actifs maintenant qui n'étaient pas en vigueur à ce moment.

Ce que la vue actuelle de R-182 montre n'est pas nécessairement ce sur quoi la décision a été basée.

Et R-182 n'était peut-être même pas la règle gagnante. Plusieurs règles s'appliquaient probablement simultanément :

R-182  →  ALLOW
R-431  →  REVIEW
R-817  →  BLOCK

règle de précédence  →  R-817 gagne

La vraie question n'est pas que dit R-182 aujourd'hui ? C'est :

Pouvez-vous reconstruire la décision policy telle qu'elle a réellement été prise, pas l'expliquer en utilisant la policy d'aujourd'hui ?

Le problème de reconstruction

Dans beaucoup d'architectures, reconstruire une décision historique exige de recoller plusieurs sources :

decision logs           ce qui a été écrit dans le storage
+
versions de règles      quelles règles existaient à cet instant
+
overrides               quelles exceptions étaient actives
+
contexte                quels faits étaient disponibles
+
approbations            quelles décisions humaines avaient été enregistrées
+
config de précédence    comment les ties étaient cassés
=
décision telle qu'elle s'est produite

Chacune de ces sources vit dans un système différent, souvent avec sa propre policy de rétention. La reconstruction est faisable, mais coûteuse et fragile.

Knowledge traite la reconstruction comme une propriété native de chaque décision, pas comme un effort d'engineering downstream.

Ce que Knowledge préserve pour chaque décision

Chaque appel /check et /resolve qui produit un verdict écrit une ligne Consultation qui fige :

• Le contexte envoyé par le caller - tous les faits, leurs sources, leur verification status
• Les versions de règles applicables à cet instant (snapshots immuables)
• La règle dominante et le trace de précédence qui y a mené
• Les overrides en vigueur et comment ils ont neutralisé ou shapé le résultat
• Le scope schema en effet pour ce tenant
• Un normative hash - agrégat SHA-256 des versions de règles citées + overrides actifs + configuration de précédence + flags universal-rule

Étant donné un consultation_id, la décision peut être reconstruite exactement. Pas par inférence de logs. À partir d'un état gelé.

Replay d'une décision

Étant donné un ID de consultation, Knowledge retourne la décision telle qu'elle s'est produite :

Decision                 :  BLOCKED
Consultation             :  cns-9a8b7c
Decided at               :  2025-02-14T09:12:00Z

Applicable rule versions :
  R-182 v4  (severity: informative)
  R-291 v7  (severity: hard_block)
  R-817 v2  (severity: absolute_ban)

Overrides in force       :
  aucun

Dominating rule          :  R-817 v2
Precedence tie-broken by :  severity (absolute_ban > hard_block > informative)

Context at decision      :
  jurisdiction    = FR
  client_type     = individual
  pep_match       = true                        (source: screening_vendor)
  risk_score      = 0.83                        (source: risk_engine)

Approval trail           :  aucun requis
Normative hash           :  sha256:9f2a...

Tout ce dont la reconstruction a besoin est dans une seule requête, peuplé depuis un état qui a été gelé au moment de décision. La règle R-817 est maintenant en v4 en production ; la Consultation retourne toujours v2 parce que c'est ce qui s'appliquait.

Expliquer et la policy et la décision

Deux questions différentes portent des réponses très différentes. Knowledge les sépare pour que chacune ait une surface first-class.

Le governance log répond à « pourquoi cette règle existe ? » La Consultation répond à « pourquoi cette règle a-t-elle fired sur ce cas ? » Les équipes compliance ont besoin des deux, depuis la même surface d'audit.

Comment le replay reste déterministe à travers les années

Vérification cryptographique (quand signed-verdict est activé)

Quand le déploiement a le verdict signing configuré, chaque champ audit-relevant de la décision (action, actor, resource, parameters, outcome, versions de règles citées, normative hash) est inclus dans une enveloppe JWS ES256 signée par la clé privée du tenant. Voir Enforcement.

Ça ajoute à l'histoire d'audit :

• Tamper-evident. Toute modification des champs de décision enregistrés invalide la signature.
• Vérifiable indépendamment. Un auditeur peut vérifier une décision depuis cold storage, des années plus tard, contre le JWKS du tenant, sans aucune dépendance à ce que Knowledge soit en ligne.

Related