Sources → mesure → grade → rapport immuable
Chaîne de provenance inKore
Défendez chaque chiffre revenue. Refusez ceux qui ne tiennent pas.
inKore produit un rapport d’attribution personnalisable par nom et couleurs où chaque mesure porte son grade, sa provenance et sa sensibilité au modèle. Quand la preuve manque, le rapport dit précisément pourquoi.
Palier 1 uniquement aucune donnée client ni métrique simulée sur cette page
iK
preuve en revue
Rapport défendableContrat local · aucune donnée client
Mesure candidate
grade requis
paid_search.revenue
01
Sources rapprochéesplateforme · analytics · CRM
sources
02
Trois modèles comparéspremier · dernier · linéaire
models
03
Grade ou refus nommécausal · corrélationnel · déclaratif
grade
04
Version partagéeimmuable · jeton aléatoire · expiration
report
Représentation du contrat — pas l’activité d’un client.
Rapport mensuel · version immuable
Le même canal sous trois modèles — avec son grade.
Paid search · revenu crédité · fenêtre et sources identiques
Comparaison inter-modèles
Structure du rapport — valeurs volontairement absentes
- Premier contact
valeur non affichéeCORRÉLATIONNEL- Dernier contact
valeur non affichéeCORRÉLATIONNEL- Linéaire
valeur non affichéeCORRÉLATIONNEL- Provenance
- sources · méthode · moteur · fenêtre · exclusions
- Sous le seuil
- RFS-SAMPLE-001 · aucun chiffre
Voir la provenance
Contester le grade
Partager la version
Ce que le dépôt contient aujourd’hui
- Mesures graduées par contrainte
- Trois modèles comparés
- Refus versionnés et contestables
- Rapports et annotations immuables
- Jetons aléatoires contrôlés par empreinte et expiration
Palier 1 · artefact de confiance
Un rapport conçu pour survivre à la contestation.
Le chiffre, sa méthode, ses limites et ce qui manque voyagent dans le même artefact.
Admettre les sources
Contrat : refuser région, signature, base légale ou schéma invalides avant persistance ; couverture locale encore partielle.
Refuse avant stockage- RFS-REGION-001
- RFS-SIG-001
- RFS-CONSENT-001
Rapprocher sans lisser
Afficher les écarts entre plateforme, analytics et CRM au lieu de les cacher.
Conserve- Valeurs manquantes explicites
- Divergences expliquées
- Lots rejouables
Graduer chaque mesure
Réserver CAUSAL aux designs randomisés ; marquer l’observationnel CORRÉLATIONNEL.
Contrainte en base- Grade non nul
- Intervalle plausible
- Provenance par chiffre
Refuser proprement
Sous le seuil, ne rien extrapoler : publier un code, une raison et une remédiation.
Section obligatoire- Échantillon
- Puissance
- Fenêtre incomplète
Publier sans réécrire
Sceller la version web et PDF, puis partager un jeton aléatoire, contrôlé par empreinte et borné.
Immuable- Changelog visible
- Filigrane optionnel
- Ouverture tracée
Comparaison de sensibilité
version + SHA-256
Trois modèles, une même fenêtre, aucune certitude cachée.
Sourcesadmissibles
Mesuregraduée
Modèlescomparés
Refusnommé
Rapportscellé
GradeObligatoire
Le type de preuve voyage avec la valeur.
ProvenanceCliquable
Sources, moteur, fenêtre et exclusions.
RemédiationActionnable
Le refus indique comment relever le niveau de preuve.
Chaîne de provenance
Cinq passages séparent un chiffre plausible d’un chiffre défendable.
La progression ne dépend pas d’un score décoratif. Chaque étape conserve sa source, sa règle et son résultat observable.
La source entre — ou reçoit un refus.
Les sept fallbacks CSV existent localement. La couverture complète des refus pré-persistance et toute exécution fournisseur réelle restent à prouver.
source.received→admission.checked→accepted | RFS-*Les écarts restent dans le produit.
Le contrat rapproche plateforme, analytics et CRM sans lisser ; la réconciliation trois voies alimentée par des sources réelles reste non démontrée.
platform + analytics + CRM→divergencesLe grade voyage avec le chiffre.
CAUSAL exige un design randomisé documenté. Les modèles d’attribution observationnels restent explicitement CORRÉLATIONNELS.
method + window→measurement + gradeQuand la preuve manque, le nombre disparaît.
Échantillon admissible global, minimum par canal et fenêtre sont vérifiés. Le garde-fou de puissance du lift reste à implémenter avant toute revendication causale.
evidence threshold→measurement | refusalLa version publiée ne change plus.
Le web et le PDF portent le même contenu. Correction, annotation et partage créent des traces versionnées sans réécriture.
report→immutable version→hashed capability tokenMesures graduées
L’incertitude et la sensibilité au modèle sont visibles de face.
Le rapport compare les mêmes canaux sous trois modèles et ouvre la provenance de chaque cellule. Une réponse invalide est refusée en bloc.
ObjetPreuve attendueComportement
MeasurementGrade + méthode + fenêtreNOT NULL, jamais implicitemodel_comparisonMême scope et mêmes sourcesPremier · dernier · linéairereconciliationPlateforme + analytics + CRMÉcarts visibles et expliquésRefusalSeuil non atteintAucun nombre de remplacementRapport web défendable
Grade, intervalle, provenance et contestation restent attachés à chaque mesure.
PDF personnalisé
Nom, couleurs, version, hash, refus et provenance sont rendus. Le logo ne l’est pas dans l’export local.
Publication immuable
Le flux local exige un motif scellé par nouvelle version et rend séparément les annotations append-only.
Partage borné
Jeton aléatoire vérifié par empreinte, expiration, filigrane optionnel et ouverture journalisée.
Refus & contestation
Dire « je ne sais pas » fait partie du rapport.
Le refus n’est ni une erreur masquée ni une note de bas de page. Il porte un code stable, explique le seuil manquant et ouvre une voie de remédiation et de contestation.
- 01Catalogue versionné
Condition machine, message humain, remédiation et voie de recours.
- 02Section non désactivable
Chaque rapport montre ce qu’il refuse de chiffrer sur sa période.
- 03Contestation tracée
Un refus ou un grade peut être contesté sans réécrire le passé.
- 04Bornes système
Une politique locale ne descend jamais sous les invariants I1–I3.
refusal.catalog.v1append-only
01
RFS-SAMPLE-001échantillon insuffisant02
value = nullaucune approximation03
remediationcollecter ou tester04
appeal.openrevue tracée05
new_versionsi correctionValeur publiéeInterdite sous le seuil
REFUS
Exemple de contrat — pas un refus issu d’un client.
Sources P1 · batch d’abord
Les connecteurs ne sont jamais un point de captivité.
Le cahier des charges exige une collecte en lecture seule et un fallback CSV normalisé par source. Leur exécution avec chaque fournisseur et en production reste à prouver.
Paid mediaOAuth production non établi
Google Ads · Meta · LinkedIn
Coûts et campagnes sont requis en lecture seule ; aucune action sortante au P1.
OAuth + CSV implémentés localement · lecture réelle à prouverAnalytics & CRMfournisseurs non vérifiés
GA4 · HubSpot · Pipedrive
Le rapprochement est spécifié sans déclarer une intégration live avant preuve.
OAuth + CSV implémentés localement · lecture réelle à prouverRevenufournisseur non vérifié
Stripe
Les PaymentIntents succeeded créés dans la fenêtre sont normalisés en revenu brut ; remboursements, litiges, frais et règlement net restent hors preuve.
OAuth + CSV implémentés localement · lecture réelle à prouverConversions serveurcontrat local déclaré
Webhooks signés
La signature est vérifiée avant traitement, avec rejeu borné et refus nommé.
production distante : non prouvéeTarifs de référence
Le rapport se vend seul, avant le reste de l’OS.
Ces prix sont publics. Ils ne constituent pas la preuve qu’un paiement production ou qu’un compte client réel a déjà satisfait le critère d’acceptation P1.
AgencePalier 1
99 € / client / mois
Le contrat agence prévoit nom, couleurs, provenance et refus nommés. Logo, autonomie déléguée et facturation consolidée restent à établir.
capacité commerciale non prouvéeAnnonceur directPalier 1
299 € / mois
Le même artefact défendable dans un workspace détenu par l’annonceur.
mono-workspaceRevenue OSP2+ fermé
299 / 599 / 999 €
Mesure sous contrat, décision puis exécution : aucun développement supplémentaire avant la sortie prouvée du P1.
non ouvert au titre de ce palierEssailimité
Aucune action externe
L’essai sert à produire et présenter l’artefact ; aucune action sortante sans accord explicite.
contrôle humain obligatoireÉtat du dépôt
Les statuts déclarés ne remplacent pas une preuve d’exécution.
Instantané du registre actif docs/p1-requirement-ledger.json au 27 juillet 2026. Les 74 clauses P1 et transversales restent séparées du registre historique de 213 exigences.
41 clauses sont partielles, 6 bloquées externes et 3 non commencées.
Sans reçu admissible, les 24 déclarations locales sont automatiquement rabaissées.
Aucun reçu local ou production ne scelle encore le commit, les fichiers et les tests.
La section 18 reste cumulative : le Palier 1 est NO-GO production.
Ce que « local » ne veut pas dire
Un test local n’est ni un résultat client, ni une disponibilité publique, ni une livraison distante. Les données synthétiques du sandbox ne deviennent jamais une preuve commerciale.
Anti-promesse
Ce qu’inKore refuse de maquiller.
Un chiffre sous le seuil de preuve
Une valeur absente reste absente. Un échantillon trop faible produit RFS-SAMPLE-001, jamais une approximation.
Un badge causal sans expérimentation
CAUSAL reste réservé à un design randomisé documenté ; un modèle d’attribution ne suffit pas.
Un connecteur annoncé live sans reçu
Un contrat local ou un adaptateur présent dans le dépôt n’est pas présenté comme une intégration production.
Une « source unique de vérité »
inKore expose les divergences. Il promet la version que vous pouvez défendre, pas l’effacement artificiel des écarts.
Questions directes
Des réponses sans astérisque caché.
inKore donne-t-il toujours un chiffre ?
Non. Le rapport refuse déjà les échantillons admissibles ou fenêtres insuffisants. Le contrôle de puissance du lift reste explicitement non implémenté et doit produire RFS-POWER-001 avant tout chiffre causal.
Les chiffres visibles ici viennent-ils de clients ?
Non, parce que cette page n’affiche aucun KPI client. Les nombres de la section preuve décrivent uniquement l’état du ledger local daté.
Les OAuth fournisseurs sont-ils prouvés en production ?
Non. Les sept templates et chemins CSV sont présents localement, mais aucun export client réel ni import multi-sources production n’est reçu.
Le Palier 1 est-il accepté en production ?
Non. L’acceptation exige cumulativement un compte réel multi-sources, un lien réellement ouvert par un client, un refus compris, une facturation réelle, un DSAR E2E et des reçus signés publics.
inKore · Rapport d’attribution défendable
Présentez le chiffre avec ce qui le rend défendable.
Comparez les modèles, ouvrez la provenance et montrez aussi ce que la période ne permet pas de chiffrer.
L’existence d’une page d’accès ne constitue pas une preuve de complétude production.