Code civil (France)

Une RECHERCHE sémantique sur le droit formalisé : une question ou une notion dans vos propres mots → des candidats avec adresses — prédicats avec signatures, règles, fragments d'articles. C'est la couche de DÉCOUVERTE, non de la réponse : le résultat dit QUOI demander ensuite (law_ask par signature, law_rules, law_sources) et n'établit ni un fait ni une norme. Le classement est un embedder lexical déterministe (DECISION-0040), et la similarité de texte n'est pas l'applicabilité d'une norme. Si vous connaissez le nom exact, allez directement à law_packages/law_ask ; un résultat vide ne signifie PAS que la norme n'existe pas.

Passeport d'une publication exacte : objet, interface, frontières, contrôles et performance. La section reports conserve l'historique des mesures, y compris les échecs. Les enregistrements sont paginés par JSON Pointer ; next poursuit la réponse.

Une matrice lisible par machine des producteurs Lens réellement installés, des contrôles replay/projection, des profils, des limites et des tests de contrat qui les confirment. declared_only désigne un schéma sans témoin exécutable.

Takes no parameters.

Exécuter un producteur enregistré et obtenir producerControl/0.2 pour une préparation ultérieure vérifiable d'une Lens. Le producteur n'est choisi que dans le registre livré.

À la demande explicite de l'utilisateur, répéter entre 1 et 12 appels law_ask ou law_process_run antérieurs (le cours d'une affaire, DECISION-0160), comparer strictement leurs replayControl, et préparer un document figé non public pour 24 heures. Le client ne fournit jamais la réponse machine : le serveur ne l'obtient qu'en exécutant à nouveau. Un écart dans une entrée, dans le droit, dans une ressource, dans le code du serveur, dans la bibliothèque du moteur ou dans le résultat rejette le document entier.

Publier un document préparé. La répétition avec le même preparationId renvoie de façon idempotente la même URL et le même secret de révocation distinct.

Révoquer un document publié au moyen de son secret distinct. L'identifiant public à lui seul ne donne aucun contrôle ; la révocation ferme la page HTML, l'API et le téléchargement.

Le catalogue du droit formalisé : actes, prédicats avec signatures, frontières de couverture. C'est d'ici que viennent les NOMS des prédicats — ils ne doivent jamais être inventés. Mais ne commencez PAS par le catalogue pour trouver le bon acte : l'aperçu est vaste, et le titre d'un acte coïncide rarement avec les mots d'une question (« Newton's laws of motion » ne contient pas le mot « physics »). Une question dans vos propres mots va d'abord à law_search, qui renvoie des adresses ; le catalogue sert à la signature exacte de ce que vous avez trouvé. Sans arguments — l'aperçu : une ligne par acte (clé, titre, ordre juridique, compteurs de règles, faits, signatures, normes, constantes) ; un acte entier — package="kz-gpk" ; une recherche sur les signatures, étiquettes et constantes de tous les actes — query="substring". Les trois modes sont PAGINÉS : limit et offset, le reste nommé dans le texte (`showing a–b of N; k more`) et dans structuredContent (total, truncated, next — un appel de continuation tout prêt). L'unité d'une page est nommée par pageUnit : l'aperçu et query paginent les ACTES (20 et 20 par défaut), package=… pagine les SIGNATURES d'un acte (20 par défaut, 300 au plus) — les grands codes en portent des milliers. package=… avec catalog=… pagine une liste séparée de l'acte : "questions" — le CATALOGUE DES QUESTIONS (DECISION-0190) : quelles demandes sont prévues (une question en mots, une forme, un prédicat ou des normes) et à quoi l'acte NE répond PAS, avec le type de motif ; une fiche est un modèle de demande, non une réponse, et tous les actes n'en ont pas ; "norms" — les NORMES de l'acte (modalité §107 et étiquette), "constants" — les CONSTANTES (noms des déclarations). "task-guides" — les PARCOURS DE TÂCHE (DECISION-0414) : l'ordre d'application d'un canon à un document — quoi recueillir, quelles cartes interroger et comment lire les réponses ; un parcours ne répond à rien. catalog="task-guides" est admis aussi sans package — tous les parcours du pro

Poser une question au droit formalisé. Quand la réponse est « non établi », elle porte whyNot — le rapport why_not §185 du moteur : les règles candidates et l'état de chaque conjonct (satisfait / non satisfait / indéterminé) ; les faits manquants y sont visibles et n'ont pas à être inventés. AVANT LE PREMIER appel, obtenez les noms de prédicats par law_search (une question dans vos propres mots → adresses) ou law_packages (les signatures d'un acte connu) — un nom inventé sera rejeté. Si l'outil a renvoyé une erreur ou « non établi », C'EST LA RÉPONSE : transmettez-la à l'utilisateur et ne la substituez pas par des connaissances générales sur le droit d'un autre pays. Mais « je n'ai trouvé aucun acte convenable » N'EST PAS une réponse tant que law_search n'a pas été interrogé : le silence du catalogue est une propriété de la recherche par titre, non une conclusion sur le corpus. kind='truth' — si un fait est établi (la réponse suit le §62 : établi / réfuté / contradiction / non établi) ; kind='collect' — énumérer les enregistrements ; kind='deadline' — calculer un délai sur le calendrier officiel ; kind='positions' — quelles OBLIGATIONS sont nées des faits et quels sont leurs statuts (active / fulfilled / violated, §134–§138) ; kind='why_not' — le rapport why_not §185 sur le même but, quel que soit le statut de la réponse. La réponse porte les règles appliquées, les avertissements et la provenance avec empreintes ; truth/collect portent aussi un bloc signature (types des paramètres, clôture des types, constantes ; DECISION-0139) pour la présentation. Le serveur n'invente pas : là où une norme n'est pas formalisée, la réponse est « non établi » ou une erreur.

Construire une condition nécessaire — un surensemble — pour la présélection de lignes d'une source externe (DECISION-0120). Ce n'est PAS une réponse juridique et PAS du SQL : le résultat est un arbre typé et un manifeste des extensions jusqu'à TRUE. Chaque ligne qui passe doit ensuite être calculée en entier par le moteur, avec un graphe de preuve, sur le même instantané des données. Le binding est passé comme objet épinglable ; sourceSchemaContentHash est l'empreinte réelle du schéma source et est comparée bruyamment avec l'épingle. Les faits d'affaire qui portent une provenance (origin, document, citation, extractor) sont fournis à law_ask, pas ici. Le nombre confidence est lu par l'EvidencePolicy du paquet, pas par cet outil et pas par le moteur.

Les règles du droit formalisé mises en mots : comment exactement un prédicat est dérivé (prémisses, articles sources). Appelez ceci AVANT de fournir des faits à law_ask — les règles disent quels faits sont nécessaires au lieu de les laisser à inventer. Pour les grands actes, package=… renvoie une table des matières ; le texte complet vient de predicate=…. La liste par paquet est paginée : limit (20 par défaut, 500 au plus) et offset ; le reste est nommé dans le texte (`showing a–b of N; k more`) et dans structuredContent (total, truncated, next — un appel de continuation tout prêt).

Déplier la preuve d'une réponse law_ask en une chaîne « règle ← prémisses → conclusion ». L'entrée compacte : question (les arguments law_ask d'origine, truth/collect), resultHash et codeHash issus de la provenance de la réponse. Le serveur répète le calcul et compare les empreintes ; si quelque chose a changé, il refuse explicitement. Autrement, passer l'évaluation de law_ask(proof=true). answerResource=fullAnswer.uri explique un instantané compact stocké sans recalcul et sans que le client charge des pages ; par défaut seulement la chaîne proofRef. nodeId sélectionne un nœud et toutes ses prémisses (jusqu'à 24 Ko, sinon un refus explicite). proofHash se rapporte au graphe entier ; scope marque la partie sélectionnée.

L'opération ask §168.4 (DECISION-0165, DECISION-0399) : exécuter une affaire enregistrée d'un paquet-affaire sur ses dépendances épinglées et renvoyer le document d'évaluation canonique avec une preuve et un manifeste. La question est du JSON selon query.schema.json (query), une chaîne evaluate (evaluate + queryId), un queryId enregistré sans query, ou card + args. Un refus de préparation est une erreur avec un code LDC-*, jamais une réponse vide.

Sources : par défaut de courts extraits (view=summary), 5 textes par page, avec l'adresse du texte complet dans fragments[].full. package ou fragment est requis (un StableId issu de law_search/law_rules). view=full renvoie des parties exactes du texte : textRange fixe une plage de caractères Unicode, fragments[].next est la continuation avec un contentHash. L'empreinte se rapporte à la source ENTIÈRE, non à l'extrait ni à la partie. textOffset/textLimit exigent fragment ; une continuation exige contentHash. Les listes sont paginées avec offset/limit ; le budget de réponse peut réduire une page.

Quelle est la solidité d'une conclusion : la carte du litige selon le profil d'argumentation §274 (DECISION-0039). La réponse tombe en quatre classes : SKEPTICALLY_ACCEPTED — la conclusion est invulnérable (elle survit dans l'extension grounded) ; CREDULOUSLY_ACCEPTED — seulement défendable (il existe une position pour et une contre) ; REJECTED — elle ne survit nulle part ; NO_ARGUMENT — il n'y a aucun argument. Elle construit TOUS les arguments à partir des faits et des règles de l'acte (y compris les chaînes qui n'ont pas tiré dans l'inférence ordinaire), les attaques rebut/undermine/undercut et les défaites par priorité. Les noms de prédicats viennent de law_packages. Sur les grands actes, un refus par plafond est possible — restreignez les faits ou augmentez limits.maxArguments.

De quelles étapes se compose la procédure établie par un acte, et si elle porte un défaut structurel (O-5, DECISION-0052). Les étapes, les transitions et la condition de chaque transition sont reconstruites à partir de la formalisation, non racontées : ce qui mène d'où vers où, et sous quelle condition. Le contrôle du graphe : étapes inaccessibles, transitions mortes, une transition qui n'entre dans aucune étape. Sans package — la liste des actes dont la procédure est formalisée. Une étape sans sortie est nommée mais N'EST PAS comptée comme défaut : si elle est terminale par dessein, la formalisation ne le montre pas.

Comment une affaire particulière se déroulera, étape par étape (O-5, DECISION-0052) : un journal {date, attempt?, facts?} est exécuté cadre par cadre, et le droit de chaque cadre est le droit de SA date. La réponse dit : quelles étapes ont été atteintes ; quelle transition tentée n'a produit AUCUN effet juridique (§164 — « l'acte a été accompli mais n'a pas eu lieu ») ; quelles obligations sont violées et quels délais courent ; ce qui est disponible ensuite et CE QUI MANQUE EXACTEMENT pour le reste. Les noms des transitions viennent de law_process. Étapes atteintes signifie « a-t-on déjà entré », non « où l'on est maintenant » : le noyau 0.1 ne calcule pas les points de l'état courant.

L'axe des éditions (O-2) : ce qui a changé dans un acte entre deux dates du droit — l'état des éditions, le datage des normes et le diff sémantique §215 entre les projections D1. Le verdict NOT_DATED signifie « il n'y avait rien pour le dater », non « rien n'a changé ». L'issue d'une question particulière à une date vient de law_ask avec legalTime.

Une requête LawQL déterministe sur le CLIR d'une formalisation : une question sur le modèle de l'acte lui-même, pas sur une affaire. Relations : nodes(id,kind,package,package_name,path), edges(from,to,role), anchors(node,anchor,act,locator,path), labels(node,lang,text,status), fields(node,field,value,value_kind), rules(id,strength,head_predicate,head_polarity,head_variables,body_variables,body_predicates), norms(id,modality,goal_kind,condition_predicates), positions(norm,kind,bearer_type), windows(norm,kind,deadline), imports(package,imported,semantic_hash), links(from,to,kind: imports|alias|subtype|produces|reads|anchored), literals(node,context,predicate,polarity), variables(node,context,name,type), interpretations(id,predicate,role). Fonctions : anchor, labels, short, contains, overlaps, starts_with, ends_with, position, derivation ; exists/not exists sur une variable liée ; égalité et appartenance seulement, sans arithmétique ni comparaisons d'ordre. Périmètre : corpus par package.name (par exemple kz.corpus.labour_code, pas un nom de fichier) ou un glob ; sans corpus, toute la tranche du profil ; un périmètre hors profil est vide (CORPUS_EMPTY). Exemples : `from r in rules where r.head_predicate == "urn:…#eligible" select r.id as producer, r.strength as strength, anchor(r.id) as anchors` — qui produit ; `from l in literals where l.predicate == "urn:…#eligible" select l.node as reader, l.context as context` — qui lit ; `query eligible over "pkg" { for x: Person; where applicant(x); select eligible(x); }` — inférence par le noyau. C'est une orchestration au-dessus du CLIR et du noyau ; aucune sémantique juridique nouvelle n'est implémentée ici. Au lieu du texte, une question du catalogue avec arguments : producers, readers, anchors-of, imports-of, links-of, type-step (les paramètres predicate/node/type sont des URN, pkg un package.name ou un glob). La réponse structurelle est une queryPage : resultHash du queryResult complet, snapshot (hachage de la liste des paq

Un SIGNALEMENT d'écart entre la formalisation et la source : la réponse contredit le texte épinglé, une norme de la source n'est pas exprimée par une règle, une étiquette §218 diverge du texte, une adresse est introuvable. Un signalement est une hypothèse pour le triage par un formaliseur : il ne change PAS le droit, n'atteint jamais les réponses des autres outils, et « non dérivé » ne devient pas « dérivé » à cause de lui. Une adresse est requise et vérifiée contre le catalogue : package, fragment (un StableId issu de law_sources) et/ou predicate ; callId est le X-Law-Call-Id de la réponse que vous contestez. L'entrée va dans le journal du serveur.