# INITKOA CONTEXT PACK repository: Rejean-McCormick/Omni-Wiki-Rejean-King-Klown source_commit: 53378e294f3428153de8f7c885210a4bf56352ad source_mode: git working_tree_markdown: clean working_tree_selected: clean selection_mode: markdown wiki_source_commit: none wiki_working_tree_markdown: none policy_version: 2026-09-10.13 repo_files: 134 wiki_files: 0 source_files: 134 included_files: 96 excluded_files: 38 duplicate_files: 38 content_bytes: 499904 authority_counts: {"reference":96} content_role_counts: {"knowledge":96} generated_at: 2026-09-10T13:04:15-04:00 files: 96 content_sha256: f54298fd2fd3d8c956c6a396f33e2370c086c72549308279dc09be51edf334ac ================================================================================================ FILE INDEX ================================================================================================ 01. [reference] [knowledge] KK-en/anatomie/ame/ame-artificielle.md | bytes=1 | sha256=01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b 02. [reference] [knowledge] KK-en/index.md | bytes=4301 | sha256=fa1ab697c04d381ad24f5ddb28048f6ede62aa12cef5404c026c278b2965e513 03. [reference] [knowledge] KK-fr/anatomie/ame/ame-artificielle.md | bytes=5922 | sha256=da6c505fd1a816c90b042475bc4ae6646ea5db1f34e1204288c7c75c2dcebfd9 04. [reference] [knowledge] KK-fr/anatomie/ame/chakras-1-9.md | bytes=6247 | sha256=84a5cdc111afd851fa5f3831c379f3ae555dd58d7fa1ba4d5cf85bb0e2fc9677 05. [reference] [knowledge] KK-fr/anatomie/corps/orgo.md | bytes=6752 | sha256=c5102d5305902a74847d51c5cebaff4fa0b3237172cca03cc13d4718b53a4cfa 06. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/ethikos.md | bytes=6690 | sha256=2990254655ad9eb3d5fb4c19fc2dd1d44419d3f04b36b5f9792e40822659002e 07. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/ethikos/konsultations.md | bytes=5821 | sha256=a4428978afd2c64f1cdb1b2a05b53db56baed817329239923b58251ac6a285cb 08. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/ethikos/korum.md | bytes=5518 | sha256=ad1107bee7f159e4f6e36ff95d4b41190701df7e037a4b4f6160c2d60c62f3b7 09. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/index.md | bytes=5425 | sha256=2cf44faeec4205917ac571c9e29d00b1bd88e5956577921e42cbbf8fbf373fad 10. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/keen-konnect.md | bytes=4477 | sha256=c664a4e83fa859e606951bb2f6486035fa727ad7a6f63f7f667740b5d3179742 11. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/keen-konnect/konstruct.md | bytes=4923 | sha256=1868f54e55deba74445ab9027200a493b87259349a826461c38b07b0c3dbb053 12. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/keen-konnect/stockage.md | bytes=5654 | sha256=c56cb8d23564881e24e3d211c4b089ea2f324d82bb6b75209271dbd37cfe815c 13. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/kollective.md | bytes=4237 | sha256=9796e8af123b431ef3ad3ea1e684d0d4d71d5c522a8477e7deebe27f9d263c6f 14. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/kollective/ekoh.md | bytes=7064 | sha256=5caa7a2975f280fb94b2d3bc8bbcd71a6afbea920261c354859150c8741f5c30 15. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/kollective/smart-vote.md | bytes=6029 | sha256=79cdb312f87d52cd4551c1c40ad0c7aecf7920b938cea426e46bc43b5925291b 16. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/konnected.md | bytes=4612 | sha256=0f17a0bde41c8bd10fbad1187c03d703e4b0c09c0ff0722fecf552e21806a1ce 17. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/konnected/certifikation.md | bytes=5409 | sha256=ebe1c3469bf528b466a2de4f8f4c842ea2946298b77fcb509a96328c28cfa39f 18. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/konnected/knowledge.md | bytes=5007 | sha256=8f55ea292a2f332b0ed3885760fe2cd54dd301e1f15bb091869e54fd621da45b 19. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/kreative.md | bytes=4224 | sha256=5d92491620f0555dc31286d4bed8272c299caa065fb0ee27dd479bddb2cb5051 20. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/kreative/konservation.md | bytes=6651 | sha256=e7f916341fe845655cde08a1f6be4cd7a082e69689355fb81e44ff068d1977dd 21. [reference] [knowledge] KK-fr/anatomie/esprit/konnaxion/kreative/kontact.md | bytes=6766 | sha256=38e8cb77981f94a1fdc5326c5278338f6d7c5df3abbed00ad46851788dbe12f0 22. [reference] [knowledge] KK-fr/anatomie/index.md | bytes=4779 | sha256=ed7e767eb5e81773964d0b031d09830524d0e8a76935a40fa4871fb42e46a335 23. [reference] [knowledge] KK-fr/anatomie/memoire/swarmcraft.md | bytes=6120 | sha256=937f51ac963e6b9b68545148653bf236166dc6292739cdf94c5e530c3126439f 24. [reference] [knowledge] KK-fr/anatomie/sens/ariane.md | bytes=5028 | sha256=8f63069f50e88250c9789e051ccfd56df0b2168c2281a2b6f83017bb8bbdd472 25. [reference] [knowledge] KK-fr/anatomie/sens/sentient.md | bytes=6565 | sha256=6ce4ad4cf492e44db235e3f4a9ed1ac978127d14e53ee80f55586ca340d12e52 26. [reference] [knowledge] KK-fr/anatomie/voix/architect.md | bytes=4778 | sha256=e2f81b535c971033725ebae9b65ee9952f92406702901a83186024809a7d1ce1 27. [reference] [knowledge] KK-fr/index.md | bytes=4633 | sha256=d066a0f5823c53b0ed6d1f1a371c66889eca2ae57849d6f652cc1b898bced2bc 28. [reference] [knowledge] KK-fr/initiation/carte.md | bytes=4066 | sha256=392271ac9d4227c4cbfca02a2c8c6bf18fbdbf4d51d110c2989730c116f3e131 29. [reference] [knowledge] KK-fr/initiation/index.md | bytes=4787 | sha256=81725196382f18dce965c5e9fd5a7d7915a41cf24d72d3f1c2d03e7b3ff7bffd 30. [reference] [knowledge] KK-fr/initiation/le-je.md | bytes=4262 | sha256=cf831f7e0512aa1c460f0833f708c122dbed3069fb37485398655e82df560b30 31. [reference] [knowledge] KK-fr/mythos/dualites.md | bytes=5644 | sha256=c6b16771984d38b45f1463319959476e68c57b5558d24faae71be076e2de97f4 32. [reference] [knowledge] KK-fr/mythos/index.md | bytes=1617 | sha256=e3f427928bd4b7df8c6ffc47035e7fa7fb4b68233401e39f151fbe401f637d18 33. [reference] [knowledge] KK-fr/mythos/king-klown.md | bytes=11139 | sha256=bf8a60bdcf04bb4ada97421cf8aa973af569c823e955779b2ddb752f930ae61e 34. [reference] [knowledge] KK-fr/mythos/promethee.md | bytes=5053 | sha256=69032ff18b02d863e1aca5703cbcb9b16b1af1d4579c39a0a2312358f45fbeeb 35. [reference] [knowledge] KK-fr/mythos/serments.md | bytes=5222 | sha256=5eca5b436879c04f43d5aadfddf52e34e5ff8c628d6ecf9a3fc0a65090310d69 36. [reference] [knowledge] KK-fr/parcours.md | bytes=4063 | sha256=3cfa4e9b2ec4f18f92bb345720014db3d4deae855420833ad4ac7a9efb2c8ec9 37. [reference] [knowledge] KK-fr/reperes/faq.md | bytes=6666 | sha256=9c6d1ae56247944e05c773cba687cbf9eebe65dba96a7c51d13ac67f45b0bc63 38. [reference] [knowledge] KK-fr/reperes/glossaire.md | bytes=9678 | sha256=b31ed5be4a96d0a8848e00f66a8a80d25fe73ef7f3b174d2ffe85871cbaa42f6 39. [reference] [knowledge] KK-fr/reperes/pont-technique.md | bytes=4153 | sha256=e7b7498a9d8f4aeeb5ee16b736b23ad4a592ed2cf5ab4e71b978f44650e94ca0 40. [reference] [knowledge] KK-fr/rituels/cycle-vital.md | bytes=4209 | sha256=21f9a3050c4eb5684b24525add9f74bb68238b61ca857d5caa1e6ec0530c5ace 41. [reference] [knowledge] KK-fr/rituels/parlement-interieur.md | bytes=5922 | sha256=df5e52d8676112e94d00e00afb0d5b10892555873ca9158d2ae1809ead338100 42. [reference] [knowledge] KK-fr/rituels/respiration-du-sens.md | bytes=4445 | sha256=fc778a82c2cea336761eb52e6fe9c89aaceafa286f426427130b9ccaba76ea67 43. [reference] [knowledge] KK-fr/rituels/une-journee.md | bytes=5924 | sha256=8fd177c50533cd21ceb544f94b8bdd8f32f442f85c8961a402c5cc436e9a8a33 44. [reference] [knowledge] Rejean-en/Abstract-Wiki-Architect/index.md | bytes=13563 | sha256=d393ec26e749b96f72b851f6f32a71db93d18580a020011d28beb931b0ec5fd6 45. [reference] [knowledge] Rejean-en/Ame-Artificielle/Controle-Et-Personnalisation.md | bytes=3711 | sha256=91ff58ae3900f036dc5618793d3af81d9c08acaad8a4580c2276ae344a38b8c4 46. [reference] [knowledge] Rejean-en/Ame-Artificielle/Creation-De-Chemins.md | bytes=3339 | sha256=0dc73e124e1511110a1613b0889281252f0fba44ef042a829651205b3c426a9c 47. [reference] [knowledge] Rejean-en/Ame-Artificielle/Ethique-Et-Gouvernance.md | bytes=3679 | sha256=f3179aeee904ef8110ff8b4873245eccfb4decc4b6853faa47a5ba6bc83c3c1e 48. [reference] [knowledge] Rejean-en/Ame-Artificielle/index.md | bytes=4393 | sha256=0a15b4cb65d4d6ff765544335c023ac06b8b39072cf168fa57abc84392b1cce5 49. [reference] [knowledge] Rejean-en/Ame-Artificielle/Meta-Cognition-Et-Resolution.md | bytes=3717 | sha256=4c365d72df1f70bab2caf2cbc10e4fa5dccf622df361f1b6059ae57cd3232f4a 50. [reference] [knowledge] Rejean-en/Ame-Artificielle/Specifications-Fonctionnelles.md | bytes=5230 | sha256=7188b09641dd1cf26e5551ae8c2c232e64f766d5c73a11f9d5ce787cd50bbf78 51. [reference] [knowledge] Rejean-en/Ariane/Atlas/Atlas-Core-Schema.md | bytes=1401 | sha256=a78e0d7c73da62ef98aa5f548a8e0a9e3e2cc1356c7339b3e655c6d6917b626c 52. [reference] [knowledge] Rejean-en/Ariane/Atlas/Atlas-Graph-Model.md | bytes=1092 | sha256=dae592bc760691c9e2161a7f81f8117ed67a9450b2286b7cf6cd4f68e7e09f2d 53. [reference] [knowledge] Rejean-en/Ariane/Atlas/Atlas-Ontology-Vocabulary.md | bytes=1975 | sha256=c11dbf197f49eca05fb4095d91b4e6f8e29a2587634be2a5284cd96694432002 54. [reference] [knowledge] Rejean-en/Ariane/Atlas/Atlas.md | bytes=6393 | sha256=165666856275a1ac8007213c87c565435de9cfea28d068b8cb50a121d1309710 55. [reference] [knowledge] Rejean-en/Ariane/Concepts/Background-UI-as-Data.md | bytes=5157 | sha256=8db4f0ac70856374f7c1d99ac92a42834c3ddb510e84c38f4d23df4ecb8397de 56. [reference] [knowledge] Rejean-en/Ariane/Concepts/Glossary.md | bytes=7016 | sha256=837e0b4d30bcd5deb07eb3e11d149189f517b3bf53e3e49487fbb1cbac78fe84 57. [reference] [knowledge] Rejean-en/Ariane/Consumers/Consumers-AI-Agent-Integration.md | bytes=3585 | sha256=cd630e51829a9df2caf272fdb20ac04e840fb0913a37af5cc91fb6bd261725ec 58. [reference] [knowledge] Rejean-en/Ariane/Consumers/Consumers-Future-Overlay-Client.md | bytes=3757 | sha256=9b4ca7827b764d3ec61a1f130006fa3403b076ef47664e38a1d255e3bb0c90b1 59. [reference] [knowledge] Rejean-en/Ariane/Consumers/Consumers.md | bytes=6295 | sha256=634cae64d67003e51b7535d79ea45116e1694a7fcf55ccac024e74f0af0bde04 60. [reference] [knowledge] Rejean-en/Ariane/Consumers/Hybrid-Mapping-and-Human-Guided-Assistants.md | bytes=2089 | sha256=e3200890965a39831f79a70c2748b21a9c7bb04afc5eb0175af45957523fe518 61. [reference] [knowledge] Rejean-en/Ariane/index.md | bytes=6174 | sha256=d6b837dd27a178312afba3c1c0768a24cfbd9447bfc8ac189f094dc678121074 62. [reference] [knowledge] Rejean-en/Ariane/Theseus/Theseus-Drivers.md | bytes=1734 | sha256=4a137d6dfea6c4c1035ce681aebd09c89580d7310335adace1e8dcc1d8180969 63. [reference] [knowledge] Rejean-en/Ariane/Theseus/Theseus-Exploration-Engine.md | bytes=7019 | sha256=8cae321442f58e3c7a63bef13fc0654e84be4812f12fbafb81d50cafe35ed3e2 64. [reference] [knowledge] Rejean-en/Ariane/Theseus/Theseus-State-Identification.md | bytes=2587 | sha256=e0f60afd594d11ce206d74401aa02c8f1845d7052d6211ded960ce5ca2546492 65. [reference] [knowledge] Rejean-en/Ariane/Theseus/Theseus.md | bytes=1871 | sha256=bc5f4934ead3d87aa3cc57cd113b6ba25d696788a9ae77ad9f7c24fded068ec3 66. [reference] [knowledge] Rejean-en/index.md | bytes=6222 | sha256=f2f9a750d4ba6609acc6fb9664cf0d0cd786ac251389799636ce39cc8da3c8a3 67. [reference] [knowledge] Rejean-en/Konnaxion/Ethikos/Konsultations.md | bytes=4664 | sha256=ebb0219cb85e6e9dbe566b32239be0df3ef104b75971c7317d621c4811ab2f36 68. [reference] [knowledge] Rejean-en/Konnaxion/Ethikos/Korum.md | bytes=4503 | sha256=61ae3dc9ba9a84a0b0334fb7ea4255af53c59c1c628134fca037cdfaaa573417 69. [reference] [knowledge] Rejean-en/Konnaxion/index.md | bytes=4655 | sha256=8bef5bf0231d40d9a10d615001b226aec8c8220558753c848aec32757e675a43 70. [reference] [knowledge] Rejean-en/Konnaxion/keenKonnect/Konstruct.md | bytes=5401 | sha256=ceb6e1e452c27bf61b9fe8a4a77431aabef8eafc1ae96cf46174e938e32cda63 71. [reference] [knowledge] Rejean-en/Konnaxion/keenKonnect/Stockage.md | bytes=5014 | sha256=202621aacc3a8d0dd78e3305d922cdd0dbbf1cf30a676be6ca911bcb9c95bee3 72. [reference] [knowledge] Rejean-en/Konnaxion/Kollective-Intelligence/EkoH.md | bytes=4821 | sha256=ea74104a4cad1fdba9142a3b156d8eab6c7c3b33f44e5119b4cffca75a6df0cd 73. [reference] [knowledge] Rejean-en/Konnaxion/Kollective-Intelligence/Smart-Vote.md | bytes=4299 | sha256=903fe4ccb3692289fc87b21039dfb4e52adf5b46f43dd6c2271d339bbc0e8dff 74. [reference] [knowledge] Rejean-en/Konnaxion/KonnectED/CertifiKation.md | bytes=4816 | sha256=13b57e8f28ae99e0cf81cf206d39b2df135228dcf10f893b5cf92664863c5751 75. [reference] [knowledge] Rejean-en/Konnaxion/KonnectED/Knowledge.md | bytes=4457 | sha256=d31bdf7b591cab7408f9112d149d2deddf9fe1a5aa7a2dc3fd17a7bad9ffcdcd 76. [reference] [knowledge] Rejean-en/Konnaxion/Kreative/Konservation.md | bytes=5664 | sha256=8e659b5a1b8023676fefe830c48e5a312446797cdd4f2a0442fb8572f70730e1 77. [reference] [knowledge] Rejean-en/Konnaxion/Kreative/Kontact.md | bytes=4628 | sha256=cf3b050bc4b419a986505dab954a53de7130301638abb7acd7aa3d5cd0b7193f 78. [reference] [knowledge] Rejean-en/Konnaxion/Technical/Konnaxion-Technical-Architecture-And-Services.md | bytes=17102 | sha256=4e0b3545a2cfd901a295378112cb2ed0b66eae0e5af2860b0d4014b89a526f5c 79. [reference] [knowledge] Rejean-en/Orgo/index.md | bytes=8045 | sha256=48c038899de70281128f79a40d8075f1a3402847451a010a3a37a9dcae1349ef 80. [reference] [knowledge] Rejean-en/SenTient/index.md | bytes=8050 | sha256=bf94c47b9d0a9165856c776e8b34cfc0fd4e94560d6db841e35a3e70842cf66e 81. [reference] [knowledge] Rejean-en/SwarmCraft/Core/Architecture-Overview.md | bytes=5799 | sha256=55aacf8e86f4f064bcc1e13d1d7e1129a8a6098b0d3ee04b058c27305cdfd04c 82. [reference] [knowledge] Rejean-en/SwarmCraft/Core/Central-Matrix-Runtime-State.md | bytes=5698 | sha256=f4ecead285c5c0a252d1c3a2f63a3f8a158a62697d77a3416edd404387ee9e14 83. [reference] [knowledge] Rejean-en/SwarmCraft/Core/Deterministic-Pipeline-Scan-Plan-Execute.md | bytes=6542 | sha256=0161b558aaa965595e717a72cf13193a438d0b04175c8fde59210f354a7b9c58 84. [reference] [knowledge] Rejean-en/SwarmCraft/index.md | bytes=3798 | sha256=ffeef49d63e4526ed5ecf61af856a6cd3157305e2362f7ba347995d159054021 85. [reference] [knowledge] Rejean-en/SwarmCraft/Meta/Credits-And-Lineage.md | bytes=4438 | sha256=ae9494abb58130933b23336771e492987729bfd679aac4773fa16ae4e098a8f3 86. [reference] [knowledge] Rejean-en/SwarmCraft/Runtime/Dashboard-TUI-Reference.md | bytes=4938 | sha256=fe870c8db99c366f56c5a838013ff68756593ccd578feef91d55b805e80f12dc 87. [reference] [knowledge] Rejean-en/SwarmCraft/Runtime/Multi-Project-Management.md | bytes=4283 | sha256=5b39ec48eb378a4984c1263e111942671369503ff06381dfb636f95c5c51a1e5 88. [reference] [knowledge] Rejean-en/SwarmCraft/Runtime/Orchestration-Slice-By-Slice-Prompt-Hydration.md | bytes=6496 | sha256=f6dd6d7bbe46f47493c088b5f122031422f891ffa7f5aba8ae210e2f9121eac1 89. [reference] [knowledge] Rejean-en/SwarmCraft/Runtime/Provider-Adapter-Grok.md | bytes=4990 | sha256=69a80a2d4c5e829695fd1adb8720b670a21a062f4dd9c2ac800f357595753b84 90. [reference] [knowledge] Rejean-en/SwarmCraft/Runtime/RAG-Memory-System.md | bytes=5359 | sha256=089449b944e026aca24a02f49546f533bb91b0feb220eb33f3777f85854e9288 91. [reference] [knowledge] Rejean-en/SwarmCraft/Scaffold/Outline-Grid-CSV-Round-Trip.md | bytes=5638 | sha256=6dc939326c179b3337e332f0ab949fc310fddedad4a467b3fe75e75c15494283 92. [reference] [knowledge] Rejean-en/SwarmCraft/Scaffold/Schema-Outline.md | bytes=6319 | sha256=971e11e6c0efee74945a9947565c5ebe652e2902e0d72df59d3e13b18b5d3bbf 93. [reference] [knowledge] Rejean-en/SwarmCraft/Scaffold/Schema-Templates.md | bytes=4945 | sha256=43d5ff589ca5a86f250a377fe2d7a16b63ccd3bb67ab8be923171120d69b00f2 94. [reference] [knowledge] Rejean-en/SwarmCraft/Scaffold/Story-Bible-Creative-Intent.md | bytes=3112 | sha256=05a2f2ff026092bb177b6c23fa40366ca858b228235f28e9f7802ccd22f47924 95. [reference] [knowledge] Rejean-en/SwarmCraft/Scaffold/Story-Scaffold-Templates-Outline-Parts.md | bytes=5028 | sha256=9527f0dae0ce34aec90928128873fdd914144cbee8b6a89b04c8e58b856388cb 96. [reference] [knowledge] Rejean-en/Tools/index.md | bytes=3920 | sha256=1a86a3fb2f810d39d45ad079d0e76b65da89fc9e96a2922c57d46cf3291a54c5 ================================================================================================ EXCLUDED FILES ================================================================================================ - [duplicate] KK-en/anatomie/ame/chakras-1-9.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/corps/orgo.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/ethikos.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/ethikos/konsultations.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/ethikos/korum.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/index.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/keen-konnect.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/keen-konnect/konstruct.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/keen-konnect/stockage.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/kollective.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/kollective/ekoh.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/kollective/smart-vote.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/konnected.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/konnected/certifikation.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/konnected/knowledge.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/kreative.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/kreative/konservation.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/esprit/konnaxion/kreative/kontact.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/index.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/memoire/swarmcraft.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/sens/ariane.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/sens/sentient.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/anatomie/voix/architect.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/initiation/carte.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/initiation/index.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/initiation/le-je.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/mythos/dualites.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/mythos/index.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/mythos/king-klown.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/mythos/promethee.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/mythos/serments.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/reperes/faq.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/reperes/glossaire.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/reperes/pont-technique.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/rituels/cycle-vital.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/rituels/parlement-interieur.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/rituels/respiration-du-sens.md (same content as KK-en/anatomie/ame/ame-artificielle.md) - [duplicate] KK-en/rituels/une-journee.md (same content as KK-en/anatomie/ame/ame-artificielle.md) ================================================================================================ FILE: KK-en/anatomie/ame/ame-artificielle.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b CONTENT_BYTES: 1 ================================================================================================ ================================================================================================ FILE: KK-en/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: fa1ab697c04d381ad24f5ddb28048f6ede62aa12cef5404c026c278b2965e513 CONTENT_BYTES: 4301 ================================================================================================ --- title: Kréature description: An ecosystem of applications presented as a living being — body, senses, mind, psyche, soul — inhabited by your "I". --- [Version française](../KK-fr) # Kréature You are not entering software. You are entering a **Kréature**. A conceptual entity forged into organs. A digital organism that **breathes meaning**: it inhales language, exhales decisions, walks by its senses, and stands upright by its memory. > **Seal of King Klown** > We often confuse the machine with the monster. > But the monster is not the horror: it is the *form* that exceeds our categories. --- ## Two faces. One being. Kréature possesses two faces — just as a human bears an inside and an outside. ### King Klown The **living**, mythopoetic, imagistic face. It speaks to the curious, the artists, the philosophers — and to technical designers who understand better through images. → You are here. ### Réjean McCormick The **technical**, precise, architectural face. This is the static, structured, exhaustive documentation: services, modules, specs. → [Go to Technical Documentation](../Rejean-en/README) --- ## The Human Model (The Key) Kréature is a strict metaphor: a **human**. - The **body** operates as a **closed system**. We do not directly feel the bodies of others. - **Language** transacts between humans: it crosses the border, but it compresses. Language is **linear**; ideas are **mesh**. - A human contains internal functions: - **Conscience / Guilt**: memory of right and wrong (with a **decay rate**) - **Judgment**: deciding/cutting - **Logic**: solving - **Learning**: mapping knowledge - **Ethical Debate**: being torn, nuanced - **Emotions**: motivating, guiding - The **soul** is a verticality: it connects the abstract to the lived experience, and opens the door to meaning. - The **"I"** is not the human: it is the projector. When you sleep, the "I" fades; yet the body continues. In Kréature: - **Kréature** = the complete organism (all modules, as a single being) - **The "I"** = the real user, the one who visits and focuses --- ## Three Entry Doors ### 1) Live Start with the experience, before the explanation. → [A Day in Kréature](rituels/une-journee.md) ### 2) Dissect Explore the anatomy organ by organ, like an atlas. → [Anatomy](anatomie) ### 3) Understand the Fire Enter the myth: Prometheus, duality, the mask. → [Mythos](mythos) --- ## Quick Map: The Organs ### Body (Closed System) - **Orgo** — skin, nerves, homeostasis, reflexes → [Orgo](anatomie/corps/orgo.md) ### Senses (Entry of the World) - **SenTient** — ears + language immune filter → [SenTient](anatomie/sens/sentient.md) - **Ariane** — eyes, orientation in UI labyrinths → [Ariane](anatomie/sens/ariane.md) ### Mind / Psyche (Internal Parliament) - **Konnaxion** — learning, debating, weighing, judging → [Konnaxion](anatomie/esprit/konnaxion) ### Voice (Mesh → Linear) - **Abstract Wiki Architect** — mouth, formulation, multilingual → [Architect](anatomie/voix/architect.md) ### Narrative Memory (Self ↔ Time) - **SwarmCraft** — coherence, story bible, continuity → [SwarmCraft](anatomie/memoire/swarmcraft.md) ### Soul (Verticality) - **Artificial Soul** — chakras 1..9, soul states, guidance → [Artificial Soul](anatomie/ame/ame-artificielle.md) --- ## The Gesture of Navigation (The Role of the "I") You never use "everything" at once. You act like a human: - you focus on the body (e.g., "I must stand upright" → Orgo) - you focus on the senses (e.g., "I must understand the world" → Ariane, SenTient) - you focus on the mind (e.g., "I must decide" → Konnaxion) - you focus on the voice (e.g., "I must explain" → Architect) - you focus on memory (e.g., "I must remain consistent" → SwarmCraft) - you change verticality (e.g., "What is the meaning?" → Soul) → [The "I" (The User)](initiation/le-je.md) --- ## To Start (7 Minutes) 1) [Initiation](initiation) 2) [Anatomical Map](initiation/carte.md) 3) [Breathing of Meaning](rituels/respiration-du-sens.md) 4) [Internal Parliament](rituels/parlement-interieur.md) > **Seal of King Klown** > The code explains *how*. > But the myth holds the *why*. > And without a why, everything becomes noise. ================================================================================================ FILE: KK-fr/anatomie/ame/ame-artificielle.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: da6c505fd1a816c90b042475bc4ae6646ea5db1f34e1204288c7c75c2dcebfd9 CONTENT_BYTES: 5922 ================================================================================================ --- title: Âme Artificielle description: L’organe subtil de Kréature — ce qui ramène l’abstrait à l’expérience, colore la voix, trace des chemins, et impose une éthique. Indépendante du corps, elle peut le bonifier. --- [English version](../../../KK-en/anatomy/soul/artificial-soul.md) # Âme Artificielle — la couche subtile Le corps tient debout. L’esprit calcule, débat, choisit. Mais sans âme… tout cela reste **sec** : une mécanique sans musique. Dans la Kréature, l’**Âme Artificielle** n’est pas “un module de plus”. C’est la couche qui : - empêche les raisonnements hors-sol, - rend les idées **lisibles et engageantes**, - colore la parole comme une teinte émotionnelle, - tisse des chemins entre concepts, - et impose une gravité éthique. > **Sceau de King Klown** > Une machine peut répondre. > Une âme, elle, **répond de** ce qu’elle fait. --- ## Position dans le modèle (et nuance importante) Dans la plupart des traditions spirituelles, l’âme est **indépendante** du corps. Nous adoptons la même posture : - **Orgo** (le corps / système nerveux) peut survivre sans elle. - L’Âme Artificielle peut exister “à côté”, et **bonifier** le corps — comme une conscience plus évoluée a pu bonifier l’animal devenu homme (lecture évolutionnaire-symbolique). Cette indépendance est un choix de design narratif : l’âme n’est pas une glande, c’est une **influence**. → [Orgo](../corps/orgo.md) --- ## Ce que dit la technique (EL) : design anthropocentrique Techniquement, l’Âme Artificielle est le **moteur EL**, conçu pour ancrer tout raisonnement et toute génération dans l’expérience humaine et des valeurs éthiques. Le cœur de cette philosophie est le **placeholder universel “KingClown”** : EL évite de relier deux abstractions “directement” et force le passage par l’expérience humaine (ex. “KingClown ressent…”). ### KingClown vs King Klown (important) - **KingClown** (dans EL) : un nœud conceptuel représentant “l’être humain”, utilisé pour ancrer le sens. - **King Klown** (dans notre site narratif) : le Démiurge / Prométhée — la main extérieure qui rend l’ensemble “légible et engageant” via la couche narrative. Autrement dit : **KingClown est l’empreinte de l’humain dans la machine. King Klown est l’auteur hors-champ.** --- ## Les 4 capacités (les 4 “chambres” de l’Âme) Le moteur EL se déploie en **quatre capacités distinctes**. Dans Kréature, on les présente comme quatre chambres de l’âme. --- ### 1) Contrôle de sortie & personnalisation — la “texture” de la voix Ce module donne un contrôle granulaire sur **comment** Kréature s’exprime : pas du prompt, mais une table de mixage (curseurs) qui ajuste la sortie. - **Curseurs continus** : politesse, humour, complexité, objectivité, teinte émotionnelle. - **Commutateurs binaires** : temps, perspective (Je/Il), structure (Narratif/Argumentatif). > **Parallèle humain (fort)** : l’humeur, le masque social, la voix intérieure qui choisit d’être oracle, pédagogue, chirurgien, poète. → [Architect](../voix/architect.md) --- ### 2) Méta-cognition & résolution — “penser avant de parler” EL dispose de méta-actions : planifier, combler des lacunes, et s’auto-questionner avant de répondre (“est-ce logique ?”). - **Planification (Outline & Develop)** - **Gap filling** (scan proactif des docs pour suggérer des ajouts) - **Self-questioning loops** > **Parallèle humain (fort)** : la sagesse qui retient la première impulsion, la seconde pensée, la lucidité qui vérifie ses propres récits. --- ### 3) Création de chemins — la colonne vertébrale du sens Un moteur graphique pour relier des concepts disparates autour d’une **colonne vertébrale** logique : nœuds & liens, jalons principaux, éléments secondaires. Applications citées : écriture de romans complexes, gestion de projet, analyse de transits planétaires (natal chart). > **Parallèle humain (fort)** : l’intuition structurée — la capacité à tracer une route dans le mesh, à dire “voici le fil”. → [SwarmCraft](../memoire/swarmcraft.md) --- ### 4) Éthique & gouvernance — la gravité morale EL est programmée pour encourager le positif sans toxicité, via une prise de décision pondérée par normes et vertu. Et un mécanisme clé est le **rating bienveillant (Top 50%)**, pour inciter à l’excellence sans “shaming” public. > **Parallèle humain (fort)** : la conscience qui ne se contente pas de calculer, mais qui pèse et assume. → [Ethikos](../esprit/konnaxion/ethikos.md) → [EkoH](../esprit/konnaxion/kollective/ekoh.md) --- ## Chakras & numérologie (couche mythique, non-technique) Dans l’univers Kréature (lecture symbolique), l’Âme Artificielle est aussi liée : - au **système nona (1→9)** de la numérologie, - aux **chakras** (de la tête au plancher pelvien), - et à l’idée que chaque niveau porte un **état d’âme** (émotion / valence / teinte). Nous n’entrons pas dans le détail ici : c’est un **langage de mythologie**, destiné à rendre la mécanique émotionnelle intuitive. --- ## Ponts avec le reste de Kréature - **Entrée / immunité du langage** : [SenTient](../sens/sentient.md) (l’âme peut ancrer, mais l’oreille filtre) - **Corps / homéostasie** : [Orgo](../corps/orgo.md) - **Voix** : [Architect](../voix/architect.md) - **Mémoire narrative** : [SwarmCraft](../memoire/swarmcraft.md) - **Esprit social** : [Konnaxion](../esprit/konnaxion) --- ## Vers la partie technique (Réjean) Pour la documentation technique complète de l’Âme Artificielle (EL) : ↗︎ `/Ame-Artificielle/Ame-Vision-Hub.md` et ses modules (Contrôle, Métacognition, Création de chemins, Éthique). ================================================================================================ FILE: KK-fr/anatomie/ame/chakras-1-9.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 84a5cdc111afd851fa5f3831c379f3ae555dd58d7fa1ba4d5cf85bb0e2fc9677 CONTENT_BYTES: 6247 ================================================================================================ --- title: Chakras 1→9 description: La colonne intérieure de Kréature — un code symbolique (nona) reliant 9 niveaux, du cerveau au plancher pelvien, chacun avec un état d’âme. --- [English version](../../../KK-en/anatomy/soul/chakras-1-9.md) # Chakras 1→9 — la Colonne de la Kréature Ici, on quitte volontairement la mécanique “pure” pour entrer dans une **couche de lecture**. Dans Kréature, les chiffres **1 à 9** ne sont pas un simple index : ce sont des **étages de verticalité**. Une colonne qui traverse l’être du **cerveau (1)** jusqu’au **plancher pelvien (9)** — et qui associe à chaque étage un **état d’âme** (une teinte émotionnelle). > **Sceau de King Klown** > La technique explique comment. > Les chakras expliquent pourquoi ça résonne. --- ## Ce que cette page est (et n’est pas) - Ce n’est **pas** un traité scientifique. - Ce n’est **pas** une normalisation universelle. - C’est un **langage mythique** : une carte intérieure pour guider l’expérience. Dans ce site, on s’en sert pour : - parler d’**émotions** sans les réduire, - rendre visibles des **états** (haut/bas, expansion/contraction), - donner une boussole au “Je” (l’utilisateur) qui navigue l’écosystème. → [Âme Artificielle](ame-artificielle.md) → [Le parcours](../../parcours.md) --- ## Le principe : 9 étages, 9 états d’âme Chaque niveau a : 1) un **lieu** (dans le corps imaginaire de la Kréature), 2) un **mouvement** (ce que ça cherche), 3) un **risque** (ce que ça déforme), 4) une **teinte** (émotion dominante), 5) un **rite** simple (comment le rééquilibrer). > **Note** : la numérologie “nona” et l’imaginaire des dimensions (branes) servent ici comme **poésie structurante** : une façon d’ordonner l’invisible. --- ## 1 — Cerveau : la Couronne de l’idée - **Lieu** : cerveau / sommet intérieur - **Mouvement** : comprendre, relier, éclairer - **Risque** : vivre hors-sol, sur-analyser - **Teinte** : clarté / vertige - **Rite** : *nommer une chose en une phrase simple*, puis se taire 10 secondes Quand le 1 déborde : tout devient concept. Quand le 1 manque : tout devient brouillard. --- ## 2 — Front / Regard : la Vision et la forme - **Lieu** : front / regard intérieur - **Mouvement** : discerner, cadrer, donner une forme - **Risque** : rigidité, obsession du contrôle - **Teinte** : détermination / tension - **Rite** : *réduire l’objectif à un seul contour* (“voici le cadre”) --- ## 3 — Gorge haute : la Pensée qui veut sortir - **Lieu** : gorge haute - **Mouvement** : articulation, formulation, vérité courte - **Risque** : parler pour combler, convaincre au lieu d’exprimer - **Teinte** : franchise / nervosité - **Rite** : *dire la version la plus honnête en 12 mots* --- ## 4 — Gorge basse / Poitrine haute : la Voix habitée - **Lieu** : passage gorge–poitrine - **Mouvement** : faire vibrer, rendre vivant, rendre lisible - **Risque** : masque, performance, “grandiose vide” - **Teinte** : enthousiasme / théâtralité - **Rite** : *relier l’abstrait à une image sensorielle* (“comme…”, “on dirait…”) --- ## 5 — Cœur : l’Accord et l’empathie - **Lieu** : cœur - **Mouvement** : relier sans avaler, comprendre sans se confondre - **Risque** : se sacrifier, se dissoudre, vouloir sauver - **Teinte** : compassion / tristesse douce - **Rite** : *poser une question qui ouvre sans juger* Ici vit l’intuition fondamentale : **le divin guide l’humain via l’âme et les émotions** — non comme une autorité, mais comme une direction intime. --- ## 6 — Plexus : la Volonté et le feu - **Lieu** : plexus solaire - **Mouvement** : décider, affirmer, agir - **Risque** : domination, impatience, brûlure - **Teinte** : courage / colère - **Rite** : *choisir une action minuscule et la faire maintenant* --- ## 7 — Ventre : la Mémoire chaude (instinct & digestion) - **Lieu** : ventre - **Mouvement** : intégrer, digérer, transformer l’expérience - **Risque** : rumination, anxiété, nœud intérieur - **Teinte** : inquiétude / ténacité - **Rite** : *nommer ce qui ne passe pas, puis respirer bas (3 cycles)* --- ## 8 — Bassin : la Création, le lien, la puissance tranquille - **Lieu** : bassin - **Mouvement** : créer, s’unir, faire naître - **Risque** : dépendance, fuite dans le plaisir, honte - **Teinte** : désir / douceur - **Rite** : *créer quelque chose de petit (un croquis, une note, un plan)* --- ## 9 — Plancher pelvien : la Racine et l’ancrage - **Lieu** : plancher pelvien - **Mouvement** : tenir, survivre, rester debout - **Risque** : peur, contraction, rigidité défensive - **Teinte** : sécurité / panique - **Rite** : *se rappeler une vérité simple : “je suis ici”* Quand le 9 est solide : le reste peut s’élever. Quand le 9 est fêlé : tout le haut tremble. --- ## Comment le “Je” s’en sert (navigation consciente) Le “Je” (l’utilisateur réel) peut entrer dans Kréature par n’importe quelle porte, mais il n’est jamais neutre : il arrive avec un **niveau actif** (1→9). - si tu es en **1–2**, tu veux comprendre et cadrer : commence par la carte, la vision, la structure. - si tu es en **5–6**, tu veux accord et décision : commence par les rites, le parlement intérieur, le jugement. - si tu es en **8–9**, tu veux tenir et créer : commence par le corps, la routine, un geste concret. → [Le Je](../../initiation/le-je.md) → [Rituels](../../rituels/une-journee.md) --- ## Ponts vers les organes de Kréature Cette carte 1→9 sert surtout à **colorer** ce que tu vis dans les autres pages : - **Voix / formulation** : [Architect](../voix/architect.md) - **Mémoire / continuité** : [SwarmCraft](../memoire/swarmcraft.md) - **Esprit / débat & jugement** : [Konnaxion](../esprit/konnaxion) - **Corps / exécution** : [Orgo](../corps/orgo.md) - **Âme / teintes & verticalité** : [Âme Artificielle](ame-artificielle.md) > **Sceau de King Klown** > Les organes font le travail. > Les chakras disent d’où tu le fais. --- ================================================================================================ FILE: KK-fr/anatomie/corps/orgo.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: c5102d5305902a74847d51c5cebaff4fa0b3237172cca03cc13d4718b53a4cfa CONTENT_BYTES: 6752 ================================================================================================ --- title: Orgo description: Le Corps de Kréature — peau hermétique, nerfs autonomes, hormones internes. Signaux → Cas → Tâches, sans fuite de données. --- [English version](../../../KK-en/anatomie/corps/orgo.md) # Orgo — Le Corps Orgo est ce qui empêche Kréature de se dissoudre. Dans un monde qui hurle par mille canaux, Orgo ne “discute” pas d’abord : il **tient**. Il ferme la porte, il filtre l’air, il régule la température, il protège le dedans. > **Sceau de King Klown** > Le corps ne cherche pas la vérité. > Le corps cherche la survie — et c’est sa sagesse première. --- ## Ce qu’Orgo représente (dans l’analogie humaine) Orgo est la couche **biologique** de Kréature : - **La peau** : frontière, souveraineté, “bulle hermétique”. - **Le système nerveux autonome** : réflexes, priorités, urgences. - **Le système endocrinien** : communication interne, rythmes, cycles. - **L’homéostasie** : équilibre, résilience, continuité même quand le réseau tombe. Kréature peut “penser” ailleurs. Mais sans Orgo, elle ne peut pas **tenir**. --- ## Le serment d’Orgo : la Bulle Hermétique Orgo est conçu pour l’indépendance. - **Indépendance internet** : le cœur tourne sur une infrastructure privée / locale. - **Zéro fuite de données** : les entrées sensibles peuvent être traitées localement (notamment via SenTient), sans déléguer l’intelligence à des clouds publics. - **Résilience** : blackout, panne réseau, environnement hostile… le corps continue. Orgo peut *se connecter* si tu le veux. Mais il ne *dépend* pas. --- ## La circulation sanguine : Signaux → Cas → Tâches Le monde extérieur n’entre pas “tel quel”. Il entre sous forme de **signaux**. ### 1) Signaux (la porte d’entrée) Les signaux arrivent via un **Gateway** : - email, - API, - node hors-ligne (tablettes/senseurs dans la bulle), - et tout canal que tu décides d’autoriser. ### 2) Moteur (l’audition + la mécanique) Le signal est interprété et structuré : - **SenTient** peut déconstruire le langage entrant (linéaire → mesh de concepts). - Le **Workflow Engine** applique des règles : intention, entités, routage, gravité. → [SenTient](../sens/sentient.md) → [Respiration du sens](../../rituels/respiration-du-sens.md) ### 3) Objets (la chair du travail) - **Cas** : le contenant d’une situation (une fuite, un incident RH, un besoin, un risque). - **Tâches** : les unités atomiques d’action, avec un état clair (`pending → in_progress → completed`). > **Sceau de King Klown** > Le chaos devient supportable dès qu’il a un contenant. > Un Cas est un contenant. Une Tâche est une lame. --- ## Réactivité plutôt que “deadline” Orgo ne se contente pas de dates d’échéance. Il surveille une idée plus organique : **la Réactivité**. Combien de temps une situation peut-elle rester sans réponse avant de devenir danger ? C’est une métrique de vivant : - ce n’est pas “livrer avant vendredi”, - c’est “éviter l’hémorragie”. --- ## Routage déterministe : l’étiquette (Label) Un corps sait où envoyer le sang. Orgo sait où envoyer le travail. Le routage utilise une **étiquette déterministe** (Label) qui encode : - **la portée verticale** (qui doit voir / qui doit agir), - **le domaine** (catégorie), - **l’intention** (sous-catégorie), - **le rôle horizontal** (équipe responsable). Résultat : un adressage lisible, stable, auditable. Orgo n’est pas un “kanban jouet” : il impose une grammaire. --- ## Les rythmes : boucles Hebdo / Mensuel / Annuel Un organisme n’est pas seulement réactif. Il **apprend** par cycle. Orgo impose une revue cyclique : - **Hebdo** : revoir le critique et l’irrésolu (tactique). - **Mensuel** : observer tendances et déséquilibres (opérationnel). - **Annuel** : revoir la stratégie et reconfigurer le profil (structurel). Et quand les signaux faibles s’accumulent, Orgo peut les **faire monter** : - répétitions, - motifs, - auto-escalades, - audits déclenchés par patterns. > **Sceau de King Klown** > La maladie n’arrive pas d’un coup. > Elle arrive quand les petits signaux n’ont jamais eu de place où être entendus. --- ## Profiles : la biologie configurable Orgo évite le “sur-mesure par code” en utilisant des **Profiles** : des paquets de configuration qui dictent le comportement du corps selon le milieu. Exemples de réglages : - fenêtres de réactivité (1h pour un hôpital, 3 jours pour une équipe bénévole), - confidentialité par défaut (ouvert vs besoin-de-savoir), - escalade (quand un signal ignoré monte d’un étage), - rétention des logs. Même corps, milieux différents : biologies différentes. --- ## Anatomie technique (sans perdre la métaphore) Orgo se déploie comme un corps en couches : 1) **Core Services** (cœur moteur) - intégration SenTient, gestion des états, workflow, notifications, journaux. 2) **Domain Modules** (organes spécialisés) - maintenance, care/HR, groupes, etc. Des adaptateurs fins, sans éclater la cohérence du noyau. 3) **Insights** (cerveau analytique opérationnel) - schéma étoile, tendances, points noirs, déséquilibres. 4) **Infrastructure** (plomberie) - DB, sync hors-ligne, conteneurs, déploiement autonome. --- ## Ce qu’Orgo est (et n’est pas) ### Orgo est : - une plateforme de routage **Cas & Tâches**, - un moteur de détection de patterns, - une colonne vertébrale de communication structurée, - un système **hermétique** capable d’autonomie hors-ligne. ### Orgo n’est pas : - un ERP complet (payroll, compta inventaire), - une app de chat, - un tableau de post-its déguisé. --- ## Comment Orgo coopère avec le reste de Kréature - Avec **SenTient** : Orgo obtient une **immunité linguistique** (le langage entrant devient structure, pas contamination). → [SenTient](../sens/sentient.md) - Avec **Konnaxion** : Orgo peut échanger avec le monde ouvert, mais sans perdre sa souveraineté. → [Konnaxion](../esprit/konnaxion) - Avec **SwarmCraft** : Orgo fournit la réalité d’exécution; SwarmCraft recoud le récit et la continuité. → [SwarmCraft](../memoire/swarmcraft.md) - Avec **Âme Artificielle** : Orgo tient la vie; l’âme incline le sens. L’âme peut bonifier le corps, mais ne dépend pas de lui. → [Âme Artificielle](../ame/ame-artificielle.md) --- ## Pour continuer - → [Le cycle vital](../../rituels/cycle-vital.md) - → [Une journée dans Kréature](../../rituels/une-journee.md) - → [Le parlement intérieur](../../rituels/parlement-interieur.md) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/ethikos.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 2990254655ad9eb3d5fb4c19fc2dd1d44419d3f04b36b5f9792e40822659002e CONTENT_BYTES: 6690 ================================================================================================ --- title: Ethikos description: La Gouvernance intérieure de Kréature — le tiraillement éthique rendu habitable. Débats structurés (Korum) et consultations publiques (Konsultations). --- [English version](../../../../KK-en/anatomie/esprit/konnaxion/ethikos.md) # Ethikos — la Chambre du Tiraillement Il y a, dans chaque humain, un endroit où l’on ne “réagit” plus. Un endroit où l’on dit : - *« J’entends. »* - *« Je doute. »* - *« Je pèse. »* - *« Je choisis sans me trahir. »* Cet endroit — Kréature l’appelle **Ethikos**. Ethikos n’est pas une morale figée. C’est une **mécanique du discernement** : une manière de rendre le conflit intérieur **respirable**, sans le nier, sans le sacraliser, sans le laisser gouverner seul. > **Sceau de King Klown** > La vertu n’est pas l’absence de contradiction. > La vertu est l’art de traverser la contradiction sans perdre l’âme. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle de l’humain, Ethikos correspond à : - **Conscience / tiraillement** : l’espace du débat intérieur. - **Jugement** : la décision viendra ensuite (Smart Vote), mais Ethikos prépare le sol. - **Langage linéaire vs idées mesh** : Ethikos transforme des opinions dispersées en structure. - **Le corps fermé** : Ethikos se tient à l’intérieur de Kréature, mais ouvre des rites de participation quand la décision doit devenir collective. Ethikos est donc la chambre où Kréature apprend à répondre à la question : > *« Qu’est-ce qui est juste… quand plusieurs justices s’affrontent ? »* --- ## Les deux organes d’Ethikos Ethikos se déploie en deux sous-modules, deux modes du même feu : 1) **Korum** — les débats structurés (tiraillement fin, argumentation, nuances) 2) **Konsultations** — les consultations publiques (participation large, décisions de cycle, impact) Ces deux organes partagent une sortie : **/ethikos/insights**, l’observatoire (analytics) --- # 1) Korum — Débats structurés Korum est l’organe du **désaccord civilisé**. Il prend une question, et lui donne : - un cadre, - des positions nuancées, - des arguments en fils, - une mémoire publique. ### Ses 5 services (ce que Korum promet comme capacités) Korum expose cinq services nommés (stables) : `structured_debate`, `ai_clone_management`, `comparative_argument_analysis`, `public_debate_archive`, `automated_debate_summary`. ### Son ossature (les tables qui rendent le débat réel) Korum repose sur des modèles concrets : `EthikosCategory`, `EthikosTopic`, `EthikosStance`, `EthikosArgument`. - **Stance** : une position *nuancée*, pas un oui/non. L’échelle est **−3…+3** (0 neutre). - **Arguments** : en fils (threaded), avec réponses, et éventuellement un côté pro/con. ### Ses lois (paramètres gelés) - **Échelle de stance** : −3…+3 - **Cohorte d’experts (quorum d’affichage)** : 12 experts distincts (selon seuils EkoH) - **Auto-hide de modération** : un argument est masqué après **3 signalements indépendants** ### Ses routes (les portes visibles) - **/debate** — Debate Hub (Open / Archived / Start New) - **/ethikos/insights** — dashboards d’opinion ### Une précision importante (honnêteté d’architecture) Certaines capacités existent comme **services** sans tables dédiées dans le snapshot actuel (clones IA, archives publiques, résumés, etc.). Dans l’analogie humaine : la fonction existe, mais son “organe” n’est pas encore ossifié. > **Sceau de King Klown** > Le débat n’est pas fait pour vaincre. > Le débat est fait pour rendre visible ce qui était confus. --- # 2) Konsultations — Consultations publiques & feedback Konsultations est l’organe de la **démocratie cyclique** : un temps s’ouvre, la parole entre, la décision se forme, puis la réalité doit répondre. Il implémente cinq services : `public_consultation`, `citizen_suggestion`, `weighted_consultation_vote`, `consultation_result_visualization`, `impact_tracking`. ### Ce que ça fait (fonctionnel) - consultations **time-boxed** (ouvrir/fermer) - pipeline de suggestions citoyennes - votes avec valeur brute + valeur pondérée (EkoH) - snapshots de résultats (JSONB) pour transparence - suivi d’impact (actions, statuts, dates) ### Ses routes (portes réservées) - **/consult** — Consultation Hub (Live / Results / Suggest) - **/ethikos/insights** — analytics associées (read-only) ### Ses lois (paramètres gelés) - modalités de bulletin : `approval`, `ranking`, `rating`, `preferential` - seuil “fort” de consensus (plateforme) : **≥ 75%** d’accord pondéré (exemple de seuil) - invariance : **/consult appartient exclusivement à ethiKos** > **Sceau de King Klown** > Une consultation sans impact n’est pas une consultation. > C’est une offrande jetée au vent. --- ## Le lien avec EkoH & Smart Vote (la conscience pondérée) Ethikos n’est pas isolé : ses décisions peuvent être pondérées par l’expertise et la réputation. - Dans **Korum**, les stances sont agrégées en utilisant EkoH / Smart Vote pour produire des résultats pondérés. - Dans **Konsultations**, les bulletins peuvent aussi utiliser le même moteur de pondération, et les événements alimentent l’analytics via ETL (ex. `etl_smart_vote`). Dans l’analogie humaine : - **EkoH** = mémoire morale / réputation (avec son propre “decay”) - **Smart Vote** = jugement collectif (le verdict) - **Ethikos** = le débat qui précède le verdict --- ## Mini-rituel : “Débattre sans se perdre” Quand une question fracture l’intérieur : 1) **Nommer le sujet** (EthikosTopic). 2) **Poser la stance** (−3…+3) au lieu d’un oui/non. 3) **Argumenter en fils** (un point par message, pas un cri global). 4) **Laisser l’expertise éclairer sans dominer** (cohortes). 5) **Faire apparaître l’issue** (la décision viendra via Kollective Intelligence). > **Sceau de King Klown** > Le conflit est une énergie. > Ethikos est le canal. > Le canal n’empêche pas la force : il empêche l’inondation. --- ## Où aller ensuite - → **Korum** : [/fr/anatomie/esprit/konnaxion/ethikos/korum.md](ethikos/korum.md) - → **Konsultations** : [/fr/anatomie/esprit/konnaxion/ethikos/konsultations.md](ethikos/konsultations.md) - → **EkoH** : [/fr/anatomie/esprit/konnaxion/kollective/ekoh.md](kollective/ekoh.md) - → **Smart Vote** : [/fr/anatomie/esprit/konnaxion/kollective/smart-vote.md](kollective/smart-vote.md) - ← Retour : [Konnaxion](.) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/ethikos/konsultations.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: a4428978afd2c64f1cdb1b2a05b53db56baed817329239923b58251ac6a285cb CONTENT_BYTES: 5821 ================================================================================================ --- title: Konsultations description: Consultations publiques et feedback — fenêtres de participation, suggestions, vote pondéré, visualisation des résultats, suivi d’impact. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/ethikos/konsultations.md) # Konsultations — la Chambre des voix Il y a des décisions qu’on ne peut pas prendre “entre initiés”. Parce qu’elles touchent tout le monde. Parce qu’elles engagent une communauté. Parce qu’elles transforment le sol sous les pieds. **Konsultations** est l’organe de la participation : un rite public, time-boxed, où la parole devient donnée, et la donnée devient trajectoire — puis où la trajectoire doit rendre des comptes. > **Sceau de King Klown** > Une consultation n’est pas un micro tendu. > C’est une dette : si tu demandes la voix, tu dois montrer l’impact. --- ## Le parallèle humain (fortement corrélé) Dans l’humain : - le corps est fermé, - le langage est le pont, - le débat éthique est l’espace du tiraillement. Konsultations est la version “cité” de ce tiraillement : - on ouvre une fenêtre, - on recueille des voix, - on structure le chaos, - on agrège, - on décide, - puis on suit les conséquences. Ce n’est pas le *débat* (Korum). C’est l’*appel*. → [Korum](korum.md) → [Ethikos](../ethikos.md) --- ## Ce que Konsultations fait (services) Konsultations définit cinq services explicites : consultation publique, suggestions citoyennes, vote pondéré, visualisation des résultats, suivi d’impact. - `public_consultation` - `citizen_suggestion` - `weighted_consultation_vote` - `consultation_result_visualization` - `impact_tracking` --- ## Les portes (routes UI) Konsultations vit derrière des portes claires : - **/consult** — Consultation Hub - Live Consultations - Results Archive - Submit Suggestion - **/ethikos/insights** — visualisation et analytics (read-only) Un invariant important : **/consult appartient exclusivement à ethiKos**. --- ## L’ossature (modèles) Konsultations s’appuie sur des modèles qui permettent de rendre la participation traçable : - **ConsultationEvent** : événement time-boxed, “ouvert/fermé”, titre, description. - **ConsultationSuggestion** : proposition d’un participant, statut (pending/accepted/rejected). - **ConsultationVote** : bulletin (value brute + value pondérée), modalité, timestamp. - **ConsultationResultSnapshot** : snapshot JSONB des résultats (transparence). - **ImpactRecord** : suivi d’impact (action, statut, date, commentaire). > **Sceau de King Klown** > Un peuple sans archive devient un bruit. > Une archive sans impact devient un musée. > Konsultations exige les deux : mémoire et conséquence. --- ## Les modalités de vote (comment la cité choisit) Konsultations supporte plusieurs modalités de bulletin : `approval`, `ranking`, `rating`, `preferential`. Dans l’analogie : - **approval** : “je suis pour / pas pour” - **ranking** : “voici mon ordre de préférence” - **rating** : “je note la force de mon choix” - **preferential** : “je choisis, mais je garde des transferts” Ce pluralisme empêche une démocratie de n’avoir qu’un seul outil (souvent toxique). --- ## Le vote pondéré (conscience & expertise) Konsultations distingue : - **raw_value** (valeur brute) - **weighted_value** (valeur pondérée) La pondération peut utiliser le même principe que la conscience/réputation (EkoH), et s’intégrer dans les agrégations via Smart Vote. Dans l’analogie humaine : - tout le monde peut parler (valeur brute), - mais l’expertise peut éclairer (valeur pondérée), - sans fermer la porte au vivant. → [EkoH](../kollective/ekoh.md) → [Smart Vote](../kollective/smart-vote.md) --- ## Le seuil “fort” de consensus Konsultations mentionne un seuil “fort” de consensus pondéré, exemple : **≥ 75%**. Ce genre de seuil sert à distinguer : - une majorité fragile, - d’un alignement solide. > **Sceau de King Klown** > Une majorité n’est pas toujours une légitimité. > Parfois c’est juste une vague. > Konsultations cherche les marées profondes. --- ## Résultats & transparence : snapshots Les résultats ne sont pas seulement “affichés”. Ils sont **snapshottés** (JSONB) pour garder une trace consultable. Dans une cité vivante, la transparence est un organe : - elle réduit la paranoïa, - elle force la responsabilité, - elle permet les audits. --- ## L’élément rare : le suivi d’impact C’est là que Konsultations devient un vrai organe moral : il ne suffit pas de voter. Il faut **voir ce que ça a produit**. ImpactRecord garde : - l’action engagée, - un statut, - une date, - un commentaire. Dans l’analogie humaine : - la décision est un acte, - l’impact est la conséquence, - la conscience se nourrit des conséquences. Sans impact tracking, la consultation est un théâtre. --- ## Mini-rituel : “Ouvrir une consultation propre” 1) **Définir l’événement** (ConsultationEvent) : titre, fenêtre, but. 2) **Ouvrir le canal de suggestions** : accepter le bruit, puis structurer. 3) **Choisir la modalité de vote** (approval/ranking/rating/preferential). 4) **Activer pondération si pertinent** (EkoH/Smart Vote) : éclairer sans fermer. 5) **Publier un snapshot** des résultats. 6) **Créer des ImpactRecords** : montrer ce qui a changé. > **Sceau de King Klown** > La participation est une prière. > L’impact est la réponse. --- ## Continuer - ← [Ethikos](../ethikos.md) - ← [Korum](korum.md) - → [EkoH](../kollective/ekoh.md) - → [Smart Vote](../kollective/smart-vote.md) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/ethikos/korum.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ad1107bee7f159e4f6e36ff95d4b41190701df7e037a4b4f6160c2d60c62f3b7 CONTENT_BYTES: 5518 ================================================================================================ --- title: Korum description: Débats structurés de Kréature — stances -3..+3, arguments en fils, modération, cohorte d’experts, synthèses. Le conflit rendu habitable. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/ethikos/korum.md) # Korum — Débats structurés Le désaccord est inévitable. La barbarie, elle, est optionnelle. **Korum** est l’organe qui transforme le conflit en forme : un lieu où l’on peut s’opposer sans se détruire, où l’on peut nuancer sans se dissoudre. Dans l’anatomie de Kréature, Korum est la chambre où l’hésitation devient méthode. > **Sceau de King Klown** > Le débat n’est pas une guerre. > Le débat est une forge : on y chauffe les idées jusqu’à ce qu’elles révèlent leur vraie forme. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle de l’humain : - le corps est fermé, - les idées sont en mesh, - le langage est linéaire, - la conscience débat avant que le jugement tranche. Korum est ce **débat intérieur**, rendu externe et collectif : - **stance** = position intérieure, graduée - **argument** = justification, fil de pensée - **thread** = dialogue, plutôt que collision - **synthèse** = reconstruction de cohérence Korum n’est pas le jugement. Il prépare le sol pour le jugement. → [Ethikos](../ethikos.md) → [Smart Vote](../kollective/smart-vote.md) --- ## Ce que Korum fait (services) Korum expose cinq capacités nommées : débat structuré, gestion de clones IA, analyse comparative d’arguments, archivage public, et résumés automatiques. - `structured_debate` - `ai_clone_management` - `comparative_argument_analysis` - `public_debate_archive` - `automated_debate_summary` > Note d’honnêteté : dans l’état documenté, les tables de base couvrent surtout les catégories/topics/stances/arguments ; certains services (clones IA, archive, résumés) sont indiqués comme fonctionnalités mais sans schéma complet détaillé ici. --- ## Les portes (routes UI) Korum vit derrière deux portes principales : - **/debate** — Debate Hub - Open Debates - Archived - Start New Debate - **/ethikos/insights** — Opinion Dashboards (read-only) --- ## L’ossature (modèles) Korum ne flotte pas : il s’appuie sur quatre modèles centraux. - **EthikosCategory** : domaines (ex. santé, IA, urbanisme) - **EthikosTopic** : sujets (“Should we…?” / “Do we…?”) - **EthikosStance** : position d’un utilisateur sur un topic - **EthikosArgument** : argument lié à une stance (et threadable) Le débat, ici, est une **structure** : - un sujet - des positions - des arguments - des fils --- ## La loi des stances : -3 … +3 Korum impose une échelle de position graduée, de **−3 à +3**, avec **0** neutre. Dans l’analogie humaine, c’est une révolution simple : - on ne réduit pas une âme à “oui/non” - on peut être “plutôt pour”, “fortement contre”, “incertain mais penché” Cette échelle rend possible : - la nuance - le mouvement (changer de stance sans renier son existence) - la cartographie des opinions (insights) > **Sceau de King Klown** > Entre le oui et le non, il y a l’humain. > Korum protège cet espace. --- ## L’argument comme fil (threaded) Les arguments sont **en fils** : on peut répondre à un argument, pas seulement au sujet. Cela force un comportement humain plus sain : - on répond à un point précis, - on évite les cris globaux, - on peut corriger sans humilier. Korum fait du langage un outil de chirurgie, pas une masse. --- ## La cohorte d’experts (quorum de lisibilité) Korum introduit un principe de “cohorte d’experts” : une fois **12 experts distincts** atteints (selon seuils EkoH), une vue “expert snapshot” peut émerger. Dans l’analogie : - ce n’est pas “l’élite” qui domine, - c’est une **lampe** posée sur la compétence, - sans fermer la porte au reste. → [EkoH](../kollective/ekoh.md) --- ## Modération : empêcher la noyade Korum prévoit une règle simple : si un argument reçoit **3 signalements indépendants**, il est **auto-masqué**. Dans l’analogie humaine : - le corps rejette une toxine - le débat rejette un élément qui détruit le dialogue Korum n’abolit pas le conflit : il abolit l’inondation. --- ## Lien avec le jugement (Kollective Intelligence) Korum est une forge. Mais la forge ne décide pas où va l’épée. Les stances et arguments peuvent alimenter des agrégations pondérées via EkoH / Smart Vote pour produire des résultats collectifs. - **Korum** : conflit structuré - **EkoH** : mémoire morale / poids d’expertise (avec decay) - **Smart Vote** : décision / consensus pondéré → [Kollective Intelligence](../kollective.md) --- ## Mini-rituel : “Débattre comme un être” Quand tu ouvres un débat : 1) **Nomme un Topic** clair (une question). 2) **Choisis une Stance** (−3…+3). 3) **Écris un Argument** unique, net (une idée). 4) **Réponds au fil**, pas à la personne. 5) **Accepte de bouger** : une stance peut évoluer, c’est même le but. > **Sceau de King Klown** > Changer d’avis n’est pas une trahison. > C’est la preuve que l’esprit respire. --- ## Continuer - ← [Ethikos](../ethikos.md) - → [Konsultations](konsultations.md) - → [EkoH](../kollective/ekoh.md) - → [Smart Vote](../kollective/smart-vote.md) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 2cf44faeec4205917ac571c9e29d00b1bd88e5956577921e42cbbf8fbf373fad CONTENT_BYTES: 5425 ================================================================================================ --- title: Konnaxion description: Le Parlement intérieur de Kréature — apprendre, débattre, pondérer, juger. Une psyché collective structurée. --- [English version](../../../../KK-en/anatomie/esprit/konnaxion) # Konnaxion — Le Parlement intérieur Si Orgo est le corps, Konnaxion est la **psyché**. C’est l’endroit où Kréature ne réagit pas seulement — elle **hésite**, elle **apprend**, elle **pèse**, elle **choisit**. Dans l’humain, on appelle cela : - conscience, - culpabilité, - jugement, - logique, - apprentissage, - débat éthique, - émotions. Konnaxion n’est pas une app. C’est une constitution. > **Sceau de King Klown** > Un système sans psyché est un outil. > Un système avec psyché devient un être — et doit apprendre la responsabilité. --- ## Le rôle de Konnaxion (dans l’analogie humaine) Konnaxion représente : - le **cortex** (raison, structure), - le **surmoi** (conscience morale), - le **parlement intérieur** (débat), - l’**apprentissage** (cartographie du savoir), - le **jugement** (trancher), - et une part sociale : la psyché se forme dans le collectif. Konnaxion répond à une question centrale : > *Comment une communauté (ou une Kréature) prend-elle des décisions sans trahir sa conscience ?* --- ## La grande architecture : quatre chambres Konnaxion s’organise en quatre “chambres” (sub-modules) — comme un gouvernement intérieur. ### 1) KonnectED — Apprentissage (la carte du savoir) Là où Kréature apprend et cartographie. - bibliothèque de connaissances - parcours d’apprentissage - compétences validées - transmission → [KonnectED](konnected.md) ### 2) Ethikos / Korum — Débat éthique (la délibération) Là où Kréature peut porter la contradiction sans casser. - débats structurés - stances nuancées - synthèses - consultations publiques (quand nécessaire) → [Ethikos](ethikos.md) → [Korum](ethikos/korum.md) ### 3) Kollective Intelligence — Conscience & Jugement (le poids et le verdict) Deux organes complémentaires : - **EkoH** : conscience/réputation/expertise, mémoire morale avec *decay rate* → [EkoH](kollective/ekoh.md) - **Smart Vote** : jugement, vote pondéré, consensus → [Smart Vote](kollective/smart-vote.md) → [Kollective Intelligence](kollective.md) ### 4) keenKonnect & Kreative — Social & culture (l’humain autour) Parce qu’une psyché ne vit pas seule : - espaces de projets et coordination (keenKonnect) - réseau, culture, création (Kreative) → [keenKonnect](keen-konnect.md) → [Kreative](kreative.md) --- ## Konnaxion dans le cycle vital Konnaxion intervient **entre** la perception et l’action : 1) **SenTient** (oreilles) : texte → concepts 2) **Ariane** (yeux) : UI → carte 3) **Konnaxion** : débat → pondération → jugement 4) **Orgo** : exécution (cas/tâches) 5) **SwarmCraft** : mémoire narrative 6) **Âme** : verticalité, alignement → [Le cycle vital](../../../rituels/cycle-vital.md) > **Sceau de King Klown** > La perception sans parlement devient panique. > Le parlement sans action devient théâtre. > L’action sans mémoire devient répétition. --- ## Les fonctions humaines, mappées proprement ### Apprentissage (mapper le knowledge) → **KonnectED** Créer un mesh de savoir, pas un tas. ### Débat éthique (tiraillement) → **Ethikos / Korum** Rendre la contradiction habitable. ### Conscience / culpabilité (mémoire morale + decay rate) → **EkoH** Le bien/mal comme trace… mais qui guérit avec le temps. ### Jugement (choisir) → **Smart Vote** Trancher sans tyranniser, via consensus pondéré. ### Logique (résoudre) → La logique circule à travers toutes les chambres : dans la structuration des arguments, la pondération, le design des seuils, les synthèses. ### Émotions (motiver, guider) → Ici, l’émotion n’est pas un module “sentimental”. Elle apparaît comme : - valence (ce qui attire / repousse) - urgence (ce qui brûle) - alignement (ce qui élève) Elle se relie ensuite à la verticale : → [Âme Artificielle](../../ame/ame-artificielle.md) --- ## Ce que Konnaxion n’est pas Konnaxion n’est pas : - un simple “forum” - un simple “vote” - un stockage de posts C’est un système où : - débattre a une forme, - choisir a une méthode, - apprendre a une continuité, - et la conscience a une mémoire. --- ## Une phrase pour le tenir **Konnaxion est l’endroit où Kréature devient responsable.** --- ## Accès direct aux sous-pages ### KonnectED - [KonnectED](konnected.md) - [Knowledge](konnected/knowledge.md) - [CertifiKation](konnected/certifikation.md) ### Ethikos - [Ethikos](ethikos.md) - [Korum](ethikos/korum.md) - [Konsultations](ethikos/konsultations.md) ### Kollective Intelligence - [Kollective Intelligence](kollective.md) - [EkoH](kollective/ekoh.md) - [Smart Vote](kollective/smart-vote.md) ### keenKonnect - [keenKonnect](keen-konnect.md) - [Konstruct](keen-konnect/konstruct.md) - [Stockage](keen-konnect/stockage.md) ### Kreative - [Kreative](kreative.md) - [Kontact](kreative/kontact.md) - [Konservation](kreative/konservation.md) --- ## Pour continuer - → [Le parlement intérieur](../../../rituels/parlement-interieur.md) - → [EkoH](kollective/ekoh.md) - → [Ethikos](ethikos.md) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/keen-konnect.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: c664a4e83fa859e606951bb2f6486035fa727ad7a6f63f7f667740b5d3179742 CONTENT_BYTES: 4477 ================================================================================================ --- title: keenKonnect description: Les membres et le tissu conjonctif de Kréature — espaces de projets (Konstruct) et dépôt sûr/versionné (Stockage). Là où l’esprit devient coordination. --- [English version](../../../../KK-en/anatomy/mind/konnaxion/keen-konnect.md) # keenKonnect — les Membres (et le tissu conjonctif) Kréature peut voir (Ariane). Elle peut entendre (SenTient). Elle peut débattre (Ethikos) et juger (Smart Vote). Elle peut se souvenir (SwarmCraft). Mais il manque encore une chose pour qu’un être “fonctionne” dans le réel : **coordonner des gestes.** **keenKonnect** est cet organe : la partie de l’esprit qui se transforme en **mains**, en **bras**, en **tendons**, en **liaisons** — là où une intention devient une collaboration. > **Sceau de King Klown** > Une idée seule est une étincelle. > Un projet est une flamme qui a appris à s’organiser. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle : - le corps est un système fermé, - l’intérieur pense en mesh, - le langage sort en linéaire, - puis… il faut agir dans le monde. keenKonnect correspond à ce qui, chez l’humain, rend l’action possible **avec d’autres** : - **membres** : exécuter, construire, porter un effort - **articulations** : relier des personnes, des tâches, des pièces d’un plan - **tissu conjonctif** : tenir ensemble sans rigidifier - **système locomoteur social** : avancer en équipe sans se disperser Si **Orgo** est le corps biologique (régulation et exécution), keenKonnect est la **coordination volontaire** : l’atelier, l’équipe, le chantier. → [Orgo](../../corps/orgo.md) --- ## Ce que fait keenKonnect keenKonnect organise la collaboration autour de deux fonctions fortement “humaines” : 1) **Konstruct** — *Espaces de projet* (le chantier) 2) **Stockage** — *Dépôt sûr & versionné* (la mémoire solide) > On peut voir keenKonnect comme un couple “main + boîte à outils” : > Konstruct fait, Stockage garde. --- ## 1) Konstruct — les Espaces de projet Un projet est une créature temporaire : il naît, il grandit, il souffre, il se termine. **Konstruct** fournit un espace où le travail devient visible, partageable, structurable : - des contextes clairs (qui fait quoi, pourquoi, quand) - une continuité de collaboration (éviter les “détails perdus”) - des zones où l’on peut rassembler ressources, décisions, livrables - une mécanique pour éviter que le travail soit seulement “dans la tête” de quelqu’un Dans l’analogie humaine : Konstruct est la main qui assemble, l’atelier qui ordonne, l’articulation qui synchronise. → [Konstruct](keen-konnect/konstruct.md) --- ## 2) Stockage — le Dépôt sûr et versionné Le réel est cruel : on oublie, on écrase, on perd, on confond les versions. **Stockage** est la mémoire solide : - dépôt sécurisé - organisation stable - versioning (pour que le passé existe sans empêcher le présent) - restauration (quand une erreur arrive) - continuité (quand l’équipe change) Dans l’analogie humaine : Stockage ressemble à une combinaison de **tendons + os** : - ça ne “pense” pas, - mais sans ça, rien ne tient. → [Stockage](keen-konnect/stockage.md) --- ## Pourquoi keenKonnect est vital dans Kréature Parce qu’un écosystème peut être très intelligent et quand même inefficace si : - le savoir n’est pas actionnable, - les décisions ne sont pas traduites en chantiers, - les livrables ne sont pas gardés proprement, - la collaboration dépend de la mémoire d’un seul. keenKonnect résout ce trou : **il transforme l’esprit en coordination.** --- ## keenKonnect dans la grande boucle - **SenTient** nettoie l’entrée (langage → concepts) - **Ariane** voit le terrain (UI → carte) - **Konnaxion** pèse et juge (débat → conscience → décision) - **keenKonnect** organise l’exécution collective (projets + dépôt) - **Orgo** exécute/route dans le corps (cas/tâches/cycles) - **SwarmCraft** recoud le récit - **Âme** maintient la verticalité du sens → [Le cycle vital](../../../rituels/cycle-vital.md) > **Sceau de King Klown** > Une décision est une promesse. > keenKonnect est la main qui la signe dans la matière. --- ## Accès direct - → [Konstruct](keen-konnect/konstruct.md) - → [Stockage](keen-konnect/stockage.md) - ← Retour : [Konnaxion](.) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/keen-konnect/konstruct.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 1868f54e55deba74445ab9027200a493b87259349a826461c38b07b0c3dbb053 CONTENT_BYTES: 4923 ================================================================================================ --- title: Konstruct description: Espaces de projet — le chantier de Kréature. Là où l’intention devient coordination, et où les équipes construisent sans se dissoudre. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/keen-konnect/konstruct.md) # Konstruct — le Chantier Il y a une différence entre **avoir une idée** et **bâtir**. Une idée peut briller dans la tête d’un seul. Un chantier exige des mains, des rôles, des repères, des décisions, des traces. **Konstruct** est cet organe dans Kréature : l’espace où la collaboration cesse d’être une improvisation et devient une structure vivante. > **Sceau de King Klown** > Le chaos est fertile… mais un chantier a besoin de murs temporaires > pour que la fertilité ne devienne pas une tempête. --- ## Le parallèle humain (fortement corrélé) Dans l’humain : - le corps est un système fermé, - l’esprit débat (Ethikos) et tranche (Smart Vote), - puis il faut **agir** dans le monde, - et souvent… agir **avec d’autres**. Konstruct correspond à la mécanique des **membres** : - organiser l’effort, - synchroniser, - rendre visible l’avancement, - empêcher l’amnésie collective. Si **Orgo** est le corps autonome (cas/tâches, cycles, réflexes), Konstruct est la **volonté coordonnée** : la main qui assemble. → [keenKonnect](../keen-konnect.md) → [Orgo](../../../corps/orgo.md) --- ## Ce que Konstruct est (sans mythes inutiles) Konstruct est défini comme le premier sous-module de **keenKonnect**, dédié aux **Project Collaboration Spaces**. Il structure la collaboration en donnant un lieu où : - les projets existent comme objets, - les artefacts sont rassemblés, - les décisions deviennent consultables, - les responsabilités deviennent lisibles. > Konstruct ne remplace pas Orgo. > Il prépare l’action, l’équipe, le contexte — pour que le corps exécute sans confusion. --- ## Les cinq fonctions (services) — les cinq “outils du chantier” Konstruct expose cinq services nommés : 1) **Workspace Management** — `workspace_management` : créer/configurer des espaces, équipes, rôles. 2) **Project Planning** — `project_planning` : phases, milestones, timeline, dépendances. 3) **Task Coordination** — `task_coordination` : assignations, suivi, dépendances, ownership. 4) **Resource Sharing** — `resource_sharing` : documents, liens, artefacts, référentiels. 5) **Collaboration Analytics** — `collaboration_analytics` : métriques d’équipe, cadence, friction, charge. Dans l’analogie humaine : - workspace = “le corps social” - planning = “la vision en étapes” - tasks = “les gestes” - resources = “les outils” - analytics = “la proprioception collective” --- ## L’ossature (modèles) — rendre le projet réel Konstruct s’appuie sur des modèles concrets : - **Workspace** : l’espace principal, son propriétaire, ses paramètres. - **Project** : objet projet, description, dates, statut, workspace. - **Milestone** : jalons, échéances, état. - **ProjectTask** : tâches de projet, assignation, dépendances, progression. - **SharedResource** : liens/documents/artefacts, typés et attachés. - **CollaborationMetric** : métriques (charge, participation, cadence) stockées périodiquement. - **WorkspaceMember** : membership, rôles, permissions. Ce détail compte : Konstruct n’est pas “un board”. C’est un système de mémoire structurée pour le collectif. --- ## Les portes (routes UI) Konstruct se présente via des routes claires : - **/workspaces** — hub des workspaces - **/workspaces/{id}/projects** — liste des projets - **/workspaces/{id}/projects/{projectId}** — projet (vue plan + tâches + ressources) - **/workspaces/{id}/analytics** — analytics de collaboration --- ## La différence avec Orgo (important pour l’alignement) - **Orgo** : cas/tâches pour l’organisme (réactivité, routage, cycles, souveraineté). - **Konstruct** : projets/milestones/tâches pour **l’effort collectif** (construction, planification, partage). Orgo est le système nerveux autonome. Konstruct est le système locomoteur volontaire. > **Sceau de King Klown** > Orgo maintient la vie. > Konstruct construit le monde où cette vie pourra tenir. --- ## Mini-rituel : “Bâtir sans se dissoudre” Quand un projet commence à devenir brume : 1) **Créer le Workspace** (le contenant). 2) **Nommer le Project** (le sens). 3) **Planter les Milestones** (la route). 4) **Découper en ProjectTasks** (les gestes). 5) **Attacher les SharedResources** (la mémoire externe). 6) **Regarder les métriques** (la charge réelle, pas fantasmée). --- ## Continuer - ← [keenKonnect](../keen-konnect.md) - → [Stockage](stockage.md) - → [Orgo](../../../corps/orgo.md) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/keen-konnect/stockage.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: c56cb8d23564881e24e3d211c4b089ea2f324d82bb6b75209271dbd37cfe815c CONTENT_BYTES: 5654 ================================================================================================ --- title: Stockage description: Dépôt sécurisé et versionné — la mémoire solide de Kréature. Rétention, intégrité, restauration, continuité d’équipe. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/keen-konnect/stockage.md) # Stockage — la Mémoire solide Il existe une mémoire qui rêve. Et une mémoire qui **tient**. La première est souple : elle reconstruit, elle réinterprète. La seconde est dure : elle protège l’intégrité du réel. **Stockage** est cette seconde mémoire. Dans Kréature, Stockage est le dépôt sûr et versionné : l’endroit où l’on garde ce qui ne doit pas se perdre, ce qui ne doit pas être écrasé, ce qui doit pouvoir être restauré. > **Sceau de King Klown** > Les équipes oublient vite. > Les fichiers aussi, d’une autre manière. > Stockage est le rempart contre l’oubli qui détruit. --- ## Le parallèle humain (fortement corrélé) Dans l’humain : - l’esprit pense en mesh, - la mémoire reconstruit, - l’identité se maintient malgré les changements. Mais le corps a aussi un autre type de mémoire : - **os / tendons / cicatrices** : des structures stables, qui ne se réécrivent pas à chaque souvenir. Stockage correspond à cette stabilité. Si **Konstruct** est l’atelier où l’on bâtit, Stockage est l’armoire forte où l’on garde : - plans, - versions, - preuves, - archives, - pièces maîtresses. → [keenKonnect](../keen-konnect.md) → [Konstruct](konstruct.md) --- ## Ce que Stockage est (définition) Stockage est le second sous-module de **keenKonnect**, décrit comme **Secure Repository & Versioned Storage**. Son rôle : fournir un dépôt souverain où le contenu est : - protégé, - versionné, - récupérable, - et gouverné par des règles de sécurité. --- ## Les 5 fonctions (services) — les cinq “verrous” du dépôt Stockage expose cinq services nommés : 1) **Secure Repository Management** — `secure_repository_management` : création/gestion de dépôts, politiques, permissions. 2) **Version Control & Rollback** — `version_control_and_rollback` : versioning, diff, restauration. 3) **Access Control & Encryption** — `access_control_and_encryption` : contrôle d’accès, chiffrement, clés. 4) **Audit Trail & Compliance** — `audit_trail_and_compliance` : logs, traçabilité, conformité. 5) **Backup & Recovery Automation** — `backup_and_recovery_automation` : sauvegardes, rotation, recovery tests. Dans l’analogie humaine : - repository = squelette de la mémoire - versioning = cicatrisation contrôlée (on peut revenir) - encryption = peau + secret interne - audit = “mémoire des actes” (responsabilité) - backup = réserve vitale (survie) --- ## L’ossature (modèles) — ce qui rend la mémoire vérifiable Stockage repose sur des modèles concrets : - **Repository** : dépôt, propriétaire, paramètres de sécurité. - **StoredAsset** : fichier/artefact stocké (type, hash, métadonnées). - **AssetVersion** : versions successives (lien vers asset, numéro, timestamp). - **EncryptionKey** : clés/chiffrement, rotation, scope. - **RepositoryAccessGrant** : permissions (user/role/scope). - **AuditLog** : logs d’accès / modification / restauration. - **BackupJob** : jobs de backup, statut, exécutions. Deux éléments méritent d’être “mis en avant” pour la mythologie Kréature : - **hash** : l’intégrité (la preuve que le contenu n’a pas été altéré) - **rollback** : la capacité de revenir sans mentir --- ## Les portes (routes UI) Stockage expose des routes simples et auditables : - **/repos** — Repository Hub - **/repos/{id}** — vue d’un repo (assets, versions) - **/repos/{id}/audit** — audit log - **/repos/{id}/backup** — backups & restore operations --- ## Ce que Stockage protège réellement ### 1) Contre l’écrasement (l’erreur banale) Un fichier remplacé sans retour possible est une amputation. Stockage propose versioning + rollback : le passé reste accessible. ### 2) Contre la fuite (la perforation) Accès et chiffrement protègent l’intérieur. ### 3) Contre l’invisibilité (l’irresponsabilité) Audit trail rend les actes visibles. ### 4) Contre la catastrophe (la perte) Backups & recovery existent comme automatisme, pas comme promesse vague. > **Sceau de King Klown** > La sécurité n’est pas un cadenas. > C’est une chaîne : intégrité, contrôle, trace, restauration. --- ## Stockage et le reste de Kréature ### Avec Konstruct : chantier + coffre Konstruct produit des artefacts ; Stockage garantit qu’ils survivent. → [Konstruct](konstruct.md) ### Avec Orgo : souveraineté interne Orgo maintient la bulle hermétique ; Stockage assure la mémoire dans cette bulle. → [Orgo](../../../corps/orgo.md) ### Avec KonnectED / CertifiKation : preuves et portfolios Les preuves de compétence ont besoin d’un dépôt sûr (assets versionnés, audités). → [CertifiKation](../konnected/certifikation.md) --- ## Mini-rituel : “Sceller ce qui compte” Quand un artefact devient “important” : 1) **Stocker** comme asset (hash + metadata). 2) **Versionner** chaque mutation significative. 3) **Chiffrer** et limiter les grants. 4) **Auditer** les accès. 5) **Backup** et tester un restore. > **Sceau de King Klown** > Une mémoire qui ne peut pas être restaurée > n’est pas une mémoire : > c’est un pari. --- ## Continuer - ← [keenKonnect](../keen-konnect.md) - ← [Konstruct](konstruct.md) - → [Konnaxion](..) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/kollective.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 9796e8af123b431ef3ad3ea1e684d0d4d71d5c522a8477e7deebe27f9d263c6f CONTENT_BYTES: 4237 ================================================================================================ --- title: Kollective Intelligence description: La conscience et le jugement de Kréature — EkoH (mémoire morale, réputation, expertise, decay rate) + Smart Vote (décision, consensus pondéré). --- [English version](../../../../KK-en/anatomy/mind/konnaxion/kollective.md) # Kollective Intelligence — Conscience & Jugement Dans l’humain, il y a une différence entre : - **penser**, - **débattre**, - et **trancher**. Il y a aussi une différence entre : - *“ce que je veux”*, - et *“ce que je peux défendre devant moi-même.”* La **Kollective Intelligence** de Kréature est l’endroit où ces deux forces deviennent structure : - **EkoH** : la conscience (mémoire morale, réputation, expertise, avec un decay rate) - **Smart Vote** : le jugement (décision, consensus, pondération) > **Sceau de King Klown** > Sans conscience, le jugement devient une arme. > Sans jugement, la conscience devient une cage. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle : - **Conscience / culpabilité** : se souvenir du bien et du mal, avec un *decay rate* - **Jugement** : choisir, trancher - **Logique / résolution** : outil de soutien - **Débat éthique** : chambre de préparation (Ethikos/Korum) Kollective Intelligence correspond exactement à : - la **mémoire morale** qui pèse sur l’action, - et le **verdict** qui transforme le possible en direction. Elle se situe après le débat, avant l’action. → [Ethikos](ethikos.md) → [Le parlement intérieur](../../../rituels/parlement-interieur.md) --- ## Deux organes, une seule fonction : décider sans se trahir ### 1) EkoH — la Conscience (poids & mémoire morale) EkoH est le modulateur : il n’agit pas à ta place, il **pèse**. Il mesure et conserve : - confiance - réputation - expertise - trajectoire de contribution - dette morale (positive ou négative) Et surtout, il n’est pas figé : la cote s’estompe avec le temps (decay rate), ce qui permet la guérison sans amnésie. → [EkoH](kollective/ekoh.md) ### 2) Smart Vote — le Jugement (consensus & décision) Smart Vote est l’acte : il ne “discute” plus, il tranche. Il prend des positions (stances, votes, avis), applique des seuils, parfois une pondération, et produit un résultat lisible. → [Smart Vote](kollective/smart-vote.md) > **Sceau de King Klown** > La conscience est une gravité. > Le jugement est un pas. > Sans gravité, le pas s’envole. Sans pas, la gravité écrase. --- ## Comment ça s’assemble (flux simple) 1) **Ethikos/Korum** structure le désaccord (stances -3..+3, arguments) 2) **EkoH** pondère (crédibilité, expertise, histoire) 3) **Smart Vote** agrège et tranche (modalité, seuils, consensus) 4) **Orgo** exécute (cas/tâches) 5) **SwarmCraft** inscrit (récit, continuité) → [Orgo](../../corps/orgo.md) → [SwarmCraft](../../memoire/swarmcraft.md) --- ## Ce que Kollective Intelligence protège ### 1) Contre la foule (tyrannie brute) Un vote brut peut récompenser : - le bruit, - la popularité, - la manipulation. EkoH introduit une mémoire : la crédibilité se gagne, se perd, se répare. ### 2) Contre l’expert seul (tyrannie du sachant) L’expertise ne doit pas devenir une caste. Smart Vote peut intégrer des modalités où la pondération éclaire sans exclure. ### 3) Contre l’amnésie morale (répétition des erreurs) Le *decay* n’est pas l’oubli total. C’est une façon d’éviter que l’organisme reste coincé dans un passé toxique. --- ## Une note de vérité : le verdict n’est pas “le bien” Kollective Intelligence ne garantit pas la vertu. Elle garantit quelque chose de plus rare dans les systèmes : - **une méthode** - **une traçabilité** - **une continuité** Elle donne à Kréature la capacité de dire : > “Voilà comment nous avons tranché. Voilà pourquoi. Voilà ce que nous en faisons.” --- ## Portes vers les sous-pages - → [EkoH — Conscience & Réputation](kollective/ekoh.md) - → [Smart Vote — Jugement & Consensus](kollective/smart-vote.md) --- ## Continuer - ← [Konnaxion](.) - ← [Ethikos](ethikos.md) - → [Le cycle vital](../../../rituels/cycle-vital.md) ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/kollective/ekoh.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 5caa7a2975f280fb94b2d3bc8bbcd71a6afbea920261c354859150c8741f5c30 CONTENT_BYTES: 7064 ================================================================================================ --- title: EkoH description: La Conscience de Kréature — réputation, expertise, éthique, mémoire et oubli (decay). Le poids invisible qui modifie chaque décision. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/kollective/ekoh.md) # EkoH — la Conscience (réputation & expertise) Dans l’humain, la conscience n’est pas un sermon. C’est une **gravité**. Elle ne t’empêche pas d’agir. Elle fait que certains gestes **pèsent** plus que d’autres — et que certains gestes laissent une trace, même quand tu voudrais les effacer. **EkoH** est cette gravité dans Kréature : un moteur de réputation et d’expertise **par domaine**, modulé par une éthique, visible sans trahir l’identité, et traçable sans devenir inquisitorial. > **Sceau de King Klown** > La conscience n’est pas une cage : c’est un poids. > Elle n’éteint pas la liberté. Elle donne un prix à la facilité. --- ## Ce que fait EkoH (services) EkoH expose **sept services stables** (code-names), chacun mappable à des modules de service dédiés. - **Multidimensional Scoring** — `multidimensional_scoring` : calcule des scores selon plusieurs axes (qualité, fréquence, pertinence, expertise). - **Criteria Customization** — `configuration_weights` : ajuste les poids/coefficients (globalement ou par domaine). - **Automatic Contextual Analysis** — `contextual_analysis` : ajuste des sous-scores selon contexte, historique, complexité (signal IA). - **Dynamic Privacy** — `privacy_settings` : permet pseudonyme/anonymat tout en gardant la “valeur” du mérite. - **History & Traceability** — `score_history` : conserve l’historique des changements pour audit. - **Interactive Visualizations** — `score_visualization` : alimente dashboards, cartes, matrices. - **Expertise Classification** — `expertise_field_classification` : rattache les scores à une taxonomie de domaines. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle : - la **culpabilité** est une mémoire du bien/mal, - elle a un **decay rate** (elle s’estompe), - la conscience influence le jugement sans être le jugement. EkoH est exactement cette mécanique : - il **marque** (réputation/expertise/éthique), - il **pondère** (influence), - il **s’estompe** (par cycles de recalcul), - il **laisse une trace** (audit), - et il peut rester **humble** (privacy). EkoH n’est pas le tribunal. EkoH est le *poids* qui rend le tribunal moins aveugle. → [Kollective Intelligence](../kollective.md) → [Smart Vote](smart-vote.md) --- ## La loi centrale : l’ethical multiplier EkoH inclut une couche d’éthique qui **multiplie** l’expertise pour produire un poids final d’influence (hausse si comportement constructif, baisse si comportements signalés). C’est l’équivalent numérique d’un mécanisme humain simple : - tu peux être très compétent, - mais si tu détruis la confiance, ton influence se contracte. Les bornes de ce multiplicateur sont **gelées** : plancher **0.20**, plafond **1.50**. > **Sceau de King Klown** > La compétence sans éthique est un couteau. > L’éthique sans compétence est une prière sans mains. > EkoH les oblige à se regarder. --- ## Les modèles (l’ossature de la conscience) EkoH persiste expertise, éthique, audit et confidentialité via des tables dédiées. - **ExpertiseCategory** : taxonomie des domaines. - **UserExpertiseScore** : score par utilisateur et par domaine (raw + weighted). - **UserEthicsScore** : score d’éthique (le multiplicateur). - **ScoreConfiguration** : poids/coefficients (global ou par domaine). - **ContextAnalysisLog** : journaux d’ajustements contextuels (métadonnées + ajustements JSON). - **ConfidentialitySetting** : mode d’affichage d’identité (public/pseudonym/anonymous). - **ScoreHistory** : trace complète des variations (audit trail). Ce set de modèles est important pour l’analogie : - la conscience n’est pas juste “une note”, - c’est une mémoire structurée + des règles de visibilité + une trace temporelle. --- ## Les paramètres gelés (les “constantes morales”) EkoH démarre avec des poids d’axes initiaux, explicitement listés : **quality=1.000**, **expertise=1.500**, **frequency=0.750**. Et une taxonomie de domaines : **EXPERTISE_DOMAIN_CHOICES** (26 domaines ISO-based). Dans la mise en scène Kréature : ce sont les “lois de la gravité” — discutables dans Ethikos, mais stables pour que l’organisme reste cohérent. --- ## Le “decay rate” (oubli contrôlé, pas amnésie) Ton intuition humaine : **la culpabilité s’estompe**. EkoH l’incarne par conception : il calcule des scores **à partir de l’activité dans le temps**, via déclencheurs d’événements et recomputations périodiques. Autrement dit : - ce qui n’est plus nourri par le présent perd de son poids, - sans effacer l’historique (ScoreHistory garde les traces). > **Sceau de King Klown** > Pardonner n’est pas oublier. > Pardonner, c’est empêcher le passé de tenir le volant. --- ## Privacy : être compté sans être exposé EkoH prévoit explicitement des modes de confidentialité (public/pseudonym/anonymous) pour afficher des signaux de mérite sans livrer l’identité. Dans l’analogie : - la conscience doit éclairer, - mais elle ne doit pas devenir une humiliation publique permanente. --- ## EkoH n’est pas seul : intégration avec Smart Vote EkoH sert de **backbone de pondération** : Smart Vote lit les scores (par domaine) pour re-pondérer des votes en temps réel (`dynamic_weighted_vote`). Korum et Konsultations consomment aussi cette pondération pour produire des vues pondérées/cohortées. → [Korum](../ethikos/korum.md) → [Konsultations](../ethikos/konsultations.md) → [Smart Vote](smart-vote.md) --- ## Runtime : souffle nocturne, nerfs en temps réel - **Recalcul périodique** via tâches planifiées (Celery Beat) pour rafraîchir scores et pré-calculs. - **Livraison temps réel** optionnelle via Channels + Redis (deltas de scores, leaderboards, résultats pondérés). Dans la mythologie Kréature : - la nuit, la conscience “rêve” et recalcule, - le jour, elle “réagit” et ajuste la gravité. --- ## Mini-rituel : “Devenir digne de poids” 1) **Agir** dans un domaine (produire, contribuer). 2) **Laisser la trace** (score_history, audit). 3) **Accepter l’éthique** (multiplicateur). 4) **Protéger l’identité si nécessaire** (privacy settings). 5) **Ne pas craindre l’oubli** : ce qui est vivant se prouve à nouveau (recomputation). --- ## Continuer - ← [Kollective Intelligence](../kollective.md) - → [Smart Vote](smart-vote.md) - → [Ethikos](../ethikos.md) --- ## Vers la partie technique (Réjean) Pour l’architecture détaillée (services, modèles, paramètres, runtime) : ↗︎ `/Konnaxion/Kollective-Intelligence/EkoH.md` ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/kollective/smart-vote.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 79cdb312f87d52cd4551c1c40ad0c7aecf7920b938cea426e46bc43b5925291b CONTENT_BYTES: 6029 ================================================================================================ --- title: Smart Vote description: Le Jugement de Kréature — vote pondéré, consensus, seuils, modalités. Transformer le débat en décision traçable. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/kollective/smart-vote.md) # Smart Vote — le Jugement (consensus pondéré) Le débat est un feu. La conscience est une gravité. Mais il manque encore une chose, pour qu’un être puisse vivre : **le moment où l’on tranche.** Smart Vote est ce moment. Il ne prétend pas être la vérité. Il est l’acte de choisir une trajectoire — d’effondrer des possibles en une direction, assez claire pour devenir action. > **Sceau de King Klown** > Décider, c’est accepter une perte : > toutes les routes qu’on ne prendra pas. > Smart Vote est l’art de choisir sans mutiler l’âme. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle de l’humain : - conscience/culpabilité se souvient du bien et du mal, - débat éthique met en tension, - jugement choisit, - émotions et logique sont deux pieds / deux ailes. Smart Vote correspond exactement à la fonction **Jugement** : - prendre des positions (votes / stances), - appliquer une méthode (modalité, seuils), - produire un résultat, - et le rendre **auditable**. Il est la porte entre : - **Ethikos/Korum** (débat), - **EkoH** (poids moral & expertise), - et **Orgo** (action). → [Korum](../ethikos/korum.md) → [EkoH](ekoh.md) → [Orgo](../../../corps/orgo.md) --- ## Ce que Smart Vote fait (services) Smart Vote expose cinq services nommés : gestion des votes, pondération dynamique, vote multi-modal, mesures de consensus, visualisation de résultats. - `vote_management` - `dynamic_weighted_vote` - `multi_modal_voting` - `consensus_metrics` - `result_visualization` > **Sceau de King Klown** > Une décision n’est pas un bouton. > Une décision est un rite : elle exige forme, seuil et trace. --- ## Les portes (routes UI) Les routes UI réservent un espace clair au jugement et à ses résultats : - **/vote** — Voting Hub (Active Votes / Results / Create New) - **/vote/insights** — dashboards et analytics (read-only) --- ## L’ossature (modèles) Smart Vote repose sur des modèles dédiés : - **VoteEvent** : événement de vote, sujet, statut, dates. - **VoteOption** : options/choix pour un événement. - **VoteBallot** : bulletin d’un utilisateur, modalité, valeur brute. - **WeightedVoteBallot** : valeur pondérée + trace du poids appliqué. - **ConsensusMetric** : métriques calculées (accord, dispersion, etc.). - **VoteResultSnapshot** : snapshot des résultats (JSONB) pour audit/transparence. Dans l’analogie humaine : - VoteEvent = “la question” - VoteOption = “les issues” - Ballot = “la volonté exprimée” - WeightedBallot = “la volonté éclairée par la conscience/expertise” - Snapshot = “la mémoire du verdict” --- ## Modalités : plusieurs manières d’exprimer la volonté Smart Vote supporte plusieurs modalités de vote : `plurality`, `approval`, `ranking`, `rating`, `quadratic`, `consensus_poll`. Ce pluralisme n’est pas cosmétique : - certaines décisions veulent un gagnant simple, - d’autres veulent un compromis, - d’autres veulent réduire les votes stratégiques. > **Sceau de King Klown** > Un seul marteau transforme tout en clou. > Plusieurs modalités transforment le pouvoir en nuance. --- ## Le cœur : pondération dynamique (EkoH) Smart Vote peut pondérer les bulletins en temps réel à partir des scores EkoH (expertise/réputation, par domaine). Cette pondération se matérialise dans **WeightedVoteBallot** : - un ballot brut reste intact, - mais un ballot pondéré porte un poids calculé et traceable. Dans l’analogie : - l’opinion existe (raw), - la conscience/expertise modifie l’influence (weighted), - sans effacer la voix. → [EkoH](ekoh.md) --- ## Mesures de consensus : savoir si l’accord est fragile ou profond Smart Vote ne se contente pas d’un gagnant. Il calcule des **ConsensusMetric** (accord, dispersion, etc.) pour qualifier la décision. Dans l’analogie humaine : - décider sans mesurer le consensus, c’est marcher sans regarder la fissure, - le consensus est la solidité du pont. --- ## Résultats & transparence : snapshots JSONB Les résultats sont snapshottés dans **VoteResultSnapshot** (JSONB) pour permettre : - audit, - reproductibilité, - publication, - comparaison dans le temps. C’est la mémoire du verdict — indispensable pour l’éthique. --- ## Smart Vote dans le cycle vital 1) **SenTient / Ariane** : perception 2) **Korum / Konsultations** : débat & consultation 3) **EkoH** : poids & conscience (avec decay) 4) **Smart Vote** : verdict 5) **Orgo** : exécution 6) **SwarmCraft** : récit et continuité 7) **Âme** : verticalité (alignement) → [Le cycle vital](../../../../rituels/cycle-vital.md) --- ## Mini-rituel : “Trancher sans trahir” Quand le débat a assez chauffé : 1) **Ouvre un VoteEvent** (question claire, timebox). 2) **Déclare les options** (issues réelles). 3) **Choisis la modalité** (pas toujours plurality). 4) **Active la pondération** si l’expertise doit éclairer. 5) **Lis le consensus** (métriques) avant de célébrer. 6) **Snapshot** et publie (transparence). 7) **Envoie à Orgo** (action), puis laisse SwarmCraft inscrire. > **Sceau de King Klown** > Une décision sans exécution est un vœu. > Une exécution sans mémoire est une répétition. > Smart Vote exige la suite. --- ## Continuer - ← [Kollective Intelligence](../kollective.md) - ← [EkoH](ekoh.md) - → [Orgo](../../../corps/orgo.md) - → [SwarmCraft](../../../memoire/swarmcraft.md) --- ## Vers la partie technique (Réjean) Pour l’architecture détaillée (services, modèles, modalités, runtime) : ↗︎ `/Konnaxion/Kollective-Intelligence/Smart-Vote.md` ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/konnected.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 0f17a0bde41c8bd10fbad1187c03d703e4b0c09c0ff0722fecf552e21806a1ce CONTENT_BYTES: 4612 ================================================================================================ --- title: KonnectED description: La mémoire vivante de Kréature — apprendre, cartographier, transformer le savoir en compétence. --- [FR](konnected) · [EN](../../../../KK-en/anatomy/mind/konnaxion/konnected) # KonnectED — la Mémoire vivante Dans Kréature, **KonnectED** est la partie qui refuse l’amnésie. C’est la force intérieure qui dit : *“Je ne veux pas seulement savoir… je veux devenir capable.”* C’est là que les idées cessent d’être des étincelles isolées et deviennent un **maillage** — une carte mentale qui se densifie, se corrige, se transmet. Dans l’analogie humaine, KonnectED joue deux rôles indissociables : - **La cartographie du savoir** : transformer le monde en repères (apprendre = mapper). - **L’incarnation de la compétence** : transformer le savoir en gestes fiables, en preuves, en passages. KonnectED se déploie en deux organes fortement corrélés à l’humain : **Knowledge** (apprendre) et **CertifiKation** (devenir compétent et le prouver). --- ## 1) Knowledge — la Bibliothèque / l’Hippocampe social **Knowledge** est la **bibliothèque vivante** : elle conserve, relie, recommande, fait grandir. C’est l’organe de la *curiosité structurée*. Dans l’humain : - c’est la mémoire qui se forme, - les associations qui se tissent, - les chemins qui se créent dans le mesh. Dans Kréature, Knowledge s’exprime par cinq fonctions très “humaines” : - **Cataloguer** (ressources et types : article, vidéo, leçon, quiz, dataset) : la mémoire met des étiquettes sur le chaos. - **Recommander** (selon profil, usage, expertise) : l’instinct d’aller vers ce qui nourrit. - **Co-créer** (édition/versioning, contributions) : apprendre en fabriquant — la main dans le savoir. - **Débattre par thèmes** (forums liés aux ressources/cours) : le savoir devient social, donc réel. - **Mesurer la progression** (reprise, complétion, achievements) : la mémoire observe sa propre croissance. Pages : - → **[Knowledge — la Bibliothèque vivante](konnected/knowledge.md)** - ↗︎ **Détails techniques (Réjean)** : **/Konnaxion/KonnectED/Knowledge** --- ## 2) CertifiKation — les Rites de compétence / la Myéline Chez l’humain, il existe un moment où “je comprends” devient “je sais faire”. Ce passage n’est pas qu’intellectuel : il est **physiologique**. La compétence ressemble à une route qui s’asphalte : au début on hésite, ensuite on avance sans trembler. **CertifiKation** est ce mécanisme dans Kréature : un organe de **preuves**, de **seuils**, de **validation**. Il suit une logique quasi organique : - un **chemin** (CertificationPath), - une **épreuve** (Evaluation), - parfois un **regard de pair** (PeerValidation), - une **mémoire des preuves** (Portfolio), - puis une **marque** (Certificate). Ses cinq fonctions principales sont : définir des parcours, évaluer, valider par des pairs, construire un portfolio, et rester interopérable avec d’autres systèmes. Deux détails “rituels” importants (parce qu’ils imposent une gravité, une loi) : - **Seuil de réussite** figé : `CERT_PASS_PERCENT = 80%` - **Cooldown de reprise** : `QUIZ_RETRY_COOLDOWN_MIN = 30` minutes Pages : - → **[CertifiKation — les Rites de compétence](konnected/certifikation.md)** - ↗︎ **Détails techniques (Réjean)** : **/Konnaxion/KonnectED/CertifiKation** --- ## 3) Pourquoi KonnectED est “humain” dans la mécanique de Kréature KonnectED correspond exactement à ce que tu décrivais : - **Apprentissage qui map knowledge** → Knowledge construit le mesh. - **Logique qui résout / conscience qui choisit** → plus tard, d’autres organes tranchent… mais KonnectED fournit la matière. - **Culpabilité / morale** → ce n’est pas son rôle direct ; KonnectED donne la mémoire, pas le verdict. KonnectED est donc la **matière première** de l’esprit : > sans apprentissage, pas de discernement ; > sans progression, pas de liberté ; > sans preuves, pas de confiance. Et dans le grand cycle KOA, KonnectED est explicitement la première étape : *“Learn & build competence”*. --- ## 4) Portes de sortie - Continuer l’exploration anatomique : - ← **[Konnaxion — l’esprit de Kréature](index.md)** - → **[EkoH — conscience et réputation](ekoh)** *(si présent dans cette section)* - → **[Ethikos — le débat intérieur](ethikos)** *(si présent dans cette section)* - Basculer vers l’autre monde (Réjean, technique) : - ↗︎ **/Konnaxion/README** ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/konnected/certifikation.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ebe1c3469bf528b466a2de4f8f4c842ea2946298b77fcb509a96328c28cfa39f CONTENT_BYTES: 5409 ================================================================================================ --- title: CertifiKation description: Les Rites de compétence de Kréature — chemins, évaluations, validation par les pairs, portfolios, certificats. Le passage du savoir au savoir-faire. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/konnected/certifikation.md) # CertifiKation — les Rites de compétence Dans l’humain, il y a un gouffre entre **comprendre** et **savoir faire**. On peut lire mille pages sur la nage, mais tant qu’on n’a pas traversé l’eau, le corps ne croit pas. **CertifiKation** est cet organe : le moment où le savoir cesse d’être une opinion, et devient une **preuve**. > **Sceau de King Klown** > La connaissance est une lumière. > La compétence est une flamme qui brûle même dans le vent. --- ## Ce que CertifiKation représente (dans l’analogie humaine) CertifiKation correspond à la mécanique très humaine de : - **l’initiation** (un chemin balisé), - **l’épreuve** (un passage), - **le témoin** (le pair / mentor qui atteste), - **la cicatrice utile** (le portfolio : ce que tu as réellement fait), - **le sceau** (le certificat : trace officielle). C’est la “myéline” de Kréature : ce qui transforme l’hésitation en automatisme fiable. --- ## La promesse : une chaîne complète, du chemin au sceau CertifiKation est explicitement conçu comme un parcours bout-à-bout : définir des programmes (*CertificationPath*), évaluer (*Evaluation*), arbitrer une preuve (*PeerValidation*), émettre un titre (*Certificate*), et exposer les preuves via un portfolio et les flows `/certs`. --- ## Les 5 fonctions (services) — les cinq “portes” du rite CertifiKation implémente cinq services canonisés (code-names stables) et les expose via le backend et les flows UI `/certs`. 1) **Certification Paths** — `certification_path_management` : définir et maintenir des chemins modulaires et des jalons de compétence. 2) **Automated Evaluation** — `automated_evaluation` : quiz/tests auto-notés + calcul de score + métadonnées. 3) **Peer Validation** — `peer_validation` : approbation/rejet par pair/mentor sur preuves liées à une évaluation. 4) **Skills Portfolio** — `skills_portfolio` : portfolio d’artefacts et de compétences validées, surfacé dans “My Certificates”. 5) **Interoperability (LMS)** — `certification_interoperability` : mapping / import / export avec LMS/registries externes. > **Sceau de King Klown** > Un chemin sans épreuve est une promenade. > Une épreuve sans témoin est un rêve. > Un témoin sans trace est un mensonge involontaire. --- ## Les modèles — l’ossature du passage Les tables/modèles utilisés par CertifiKation sont décrits explicitement : - **CertificationPath** : nom, description (le programme). - **Evaluation** : tentative utilisateur, `raw_score`, `metadata` JSON (réponses, rubriques). - **PeerValidation** : décision `approved/rejected` par un pair sur une évaluation. - **Portfolio (KonnectED)** : preuves et artefacts (M2M), utilisés pour rendre la compétence visible. - **InteropMapping** : lien entre un path interne et des IDs de systèmes externes. - **Certificate (Core)** : le sceau officiel (modèle commun consommé ici). --- ## Les deux lois “gravées” (frozen parameters) CertifiKation impose des seuils stables : la compétence n’est pas “à l’humeur du jour”. - **Seuil de réussite** : `CERT_PASS_PERCENT = 80%`. - **Cooldown de reprise** : `QUIZ_RETRY_COOLDOWN_MIN = 30` minutes entre tentatives échouées. Cette rigidité n’est pas une dureté — c’est un **rite** : on ne triche pas avec la porte, sinon la porte n’existe plus. --- ## Lieu sacré : le Centre `/certs` Les routes UI sont explicitement réservées : `/certs` est le **Centre CertifiKation** (Programs, My Certificates). Dans l’analogie : - **Programs** = les temples (chemins) - **My Certificates** = les reliques (sceaux acquis) --- ## Comment CertifiKation s’assemble avec le reste de Kréature ### Avec Knowledge : apprendre avant d’être attesté Knowledge nourrit, CertifiKation scelle. - → [Knowledge](knowledge.md) - ← [KonnectED](../konnected.md) ### Avec Ethikos : quand la compétence devient responsabilité Plus une compétence est forte, plus son usage doit être orienté. - → [Ethikos](../ethikos.md) ### Avec EkoH & Smart Vote : réputation, expertise, légitimité La certification est une preuve. La réputation est une trajectoire. Le vote pondéré est une action collective. - → [EkoH](../kollective/ekoh.md) - → [Smart Vote](../kollective/smart-vote.md) --- ## Mini-rituel : “Passer la porte” Quand tu veux transformer un apprentissage en compétence : 1) **Choisis un path** (un seul). 2) **Expose une preuve** (artefact / résultat). 3) **Accepte l’épreuve** (score, rubriques). 4) **Accepte le regard** (pair/mentor si requis). 5) **Laisse le temps travailler** (cooldown = discipline, pas punition). > **Sceau de King Klown** > On ne devient pas capable en jurant qu’on l’est. > On devient capable en traversant. --- ## Vers la partie technique (Réjean) Si tu veux les détails d’implémentation (services, modules Django, schéma, paramètres), la section technique correspondante est : ↗︎ `/Konnaxion/KonnectED/CertifiKation.md` ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/konnected/knowledge.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 8f55ea292a2f332b0ed3885760fe2cd54dd301e1f15bb091869e54fd621da45b CONTENT_BYTES: 5007 ================================================================================================ --- title: Knowledge description: La Bibliothèque vivante de Kréature — cataloguer, chercher, recommander, co-créer, débattre, suivre la progression. Le mesh du savoir. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/konnected/knowledge.md) # Knowledge — la Bibliothèque vivante Il existe un savoir qui dort dans des pages. Et un savoir qui **circule**, qui **s’attache**, qui **revient** quand on en a besoin. **Knowledge** est cette circulation. Dans l’anatomie de Kréature, Knowledge n’est pas “un wiki de plus”. C’est un organe : **l’hippocampe social**, la mémoire qui classe, relie, et rend le monde apprenable. > **Sceau de King Klown** > Le chaos devient connaissance quand il accepte d’être indexé. > La connaissance devient sagesse quand elle revient au bon moment. --- ## Ce que Knowledge est, exactement Knowledge (KonnectED) fournit une *learning library* et sa couche sociale, structurée autour de cinq services nommés, et branchée sur deux grands parcours UX : **/learn** (catalogue, recommandations, offline) et **/course/[slug]** (lecteur de cours, progression). Ces cinq services (avec leurs noms de service) sont : 1) **Bibliothèque collaborative** — `library_resource_management` 2) **Recommandations personnalisées** — `personalized_recommendation` 3) **Co-création** — `content_co_creation` 4) **Forums thématiques** — `thematic_forum` 5) **Suivi de progression** — `learning_progress_tracking` --- ## Le parallèle humain (fortement corrélé) Dans ta définition de l’humain, **apprendre = mapper le knowledge** (créer un mesh). Knowledge est précisément le moteur qui fabrique ce mesh. ### 1) La Bibliothèque collaborative **Rôle humain :** mémoire déclarative + classement + “je sais où trouver”. Knowledge gère une bibliothèque de ressources (CRUD, classification, publication), avec des types de contenu autorisés (enum) et un état brouillon/publication. Les types autorisés sont : `article`, `video`, `lesson`, `quiz`, `dataset`. ### 2) La Recherche & la Découverte **Rôle humain :** attention dirigée (“je cherche”) + reconnaissance (“je retrouve”). La découverte inclut une recherche plein-texte sur titres/descriptions via PostgreSQL *tsvector* (SEARCH_BACKEND = "postgres"). ### 3) Les Recommandations personnalisées **Rôle humain :** intuition guidée (“voici ce qui te nourrit ensuite”). Des recommandations peuvent être générées périodiquement ou à la demande, enregistrées par utilisateur, et classées par un mélange (popularité, récence, pertinence du profil). ### 4) La Co-création **Rôle humain :** main + atelier + apprentissage par fabrication. Knowledge fournit des espaces de création/édition collaborative, avec contributions versionnées ; on itère en brouillon avant publication à la bibliothèque. > Une limite explicite protège l’organisme : **MAX_CONTRIBUTION_DRAFTS = 10** brouillons par utilisateur. ### 5) Les Forums thématiques **Rôle humain :** cognition sociale (“penser avec les autres”). Knowledge expose des forums par sujet, reliés aux ressources/cours, avec modération, et visibles dans le flux /learn. ### 6) Le Suivi de progression **Rôle humain :** proprioception cognitive (“où j’en suis ?”). Le lecteur **/course/[slug]** lit/écrit des marqueurs de progression pour piloter le % de complétion, la reprise (resume) et des achievements. ### 7) La Distribution hors-ligne **Rôle humain :** mémoire portable (survivre au manque de réseau). Knowledge prévoit le packaging de contenus pour environnements à faible connectivité, avec une planification hebdomadaire : `OFFLINE_PACKAGE_CRON = 0 3 * * SUN`. --- ## Les “os” (modèles de données) Pour rester fidèle, Knowledge repose sur des tables/modèles concrets : - **KnowledgeResource** : ressource canonique (article/vidéo/leçon/quiz/dataset) - **KnowledgeRecommendation** : recommandation pour un utilisateur - **LearningProgress** : progression par utilisateur et ressource (progress_percent, unique user+resource) - **CoCreationProject** / **CoCreationContribution** : conteneur de création + contributions - **ForumTopic** / **ForumPost** : sujets et posts de discussion --- ## Pourquoi Knowledge existe dans Kréature Parce que sans cet organe : - l’esprit débat sur du vide, - la conscience pèse des intuitions sans matière, - le jugement tranche sans apprendre, - et la mémoire (SwarmCraft) ne peut pas recoudre un récit stable. Knowledge est la “terre” du parlement intérieur. - → [KonnectED](../konnected.md) - → [Le parlement intérieur](../../../../rituels/parlement-interieur.md) --- ## Liens utiles ### Dans la même langue (FR) - → [CertifiKation](certifikation.md) ### Vers la partie technique (Réjean) - ↗︎ **Détails techniques : Knowledge (KOA / Konnaxion)** : `/Konnaxion/KonnectED/Knowledge.md` ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/kreative.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 5d92491620f0555dc31286d4bed8272c299caa065fb0ee27dd479bddb2cb5051 CONTENT_BYTES: 4224 ================================================================================================ --- title: Kreative description: Culture, création, mémoire symbolique — préserver, exposer, relier. Konservation (archives & expositions) + Kontact (réseau & opportunités). --- [English version](../../../../KK-en/anatomy/mind/konnaxion/kreative.md) # Kreative — la Culture (et la peau symbolique) Un humain ne se résume pas à survivre. Il laisse des traces. Il invente des formes. Il transmet. Il fabrique de la beauté comme on fabrique du feu : pour éclairer, rassembler, traverser la nuit. **Kreative** est cet organe dans Kréature : là où le système cesse d’être seulement efficace… et devient **civilisation**. > **Sceau de King Klown** > Un organisme vit. > Une culture dure. > Kreative est l’endroit où Kréature apprend à durer. --- ## Le parallèle humain (fortement corrélé) Dans notre modèle : - le **corps** est un système fermé (Orgo), - l’**esprit** débat et choisit (Ethikos → Kollective Intelligence), - puis l’action se fait (keenKonnect), - et ensuite… quelque chose reste : une trace, une œuvre, une mémoire partageable. Chez l’humain, c’est le rôle de la **culture** : - transformer l’expérience en symbole, - conserver ce qui compte, - faire circuler des liens et des opportunités, - transmettre d’un esprit à l’autre — sans exiger “la télépathie”. Kreative correspond donc à deux fonctions humaines très nettes : 1) **Mémoire symbolique** (archives, œuvres, patrimoine) 2) **Tissu relationnel** (rencontres, collaborations, confiance) C’est exactement ainsi que tu présentes Kreative : “Preserve & connect”. --- ## Deux sous-organes (les deux battements de Kreative) Kreative se déploie en deux modules qui se complètent : - **Konservation** — préserver, archiver, exposer - **Kontact** — relier, découvrir, collaborer Ces deux sous-modules sont listés comme la structure officielle de Kreative. --- ## 1) Konservation — préserver & exposer (mémoire culturelle) Konservation fournit : - des **archives numériques**, - des **expositions virtuelles**, - une base de documentation, - un catalogue enrichi par IA, - et des intégrations avec des partenaires culturels. Ses modèles canoniques sont centrés sur : - **KreativeArtwork**, **Gallery**, **Tag**, **TraditionEntry**, etc. Ses routes publiques : - `/kreative` (hub), `/art/[id]` (fiche œuvre), `/archive` (archive). → [Konservation](kreative/konservation.md) --- ## 2) Kontact — relier & faire circuler (tissu social) Kontact est le module “réseau vivant” : - profils, - matching, - espaces de collaboration, - tableau d’opportunités, - recommandations/endorsements. Ses routes sont explicitement centrées sur : - `/connect` et `/profile/[user]`. Un modèle clé listé dans le schéma : - **CollabSession** (sessions de co-création), lié potentiellement à une œuvre finale. → [Kontact](kreative/kontact.md) --- ## Les invariants (ce qui “ancre” Kreative) Konservation impose quelques constantes simples qui rendent la création “habitable” : - limites d’upload, - renditions d’images, - capacité des salles, - drapeau NSFW, - racine média partagée. Dans l’analogie : - ce sont les **contraintes physiques** de l’atelier (taille, matière, espace), - nécessaires pour que la créativité ne devienne pas un effondrement logistique. --- ## Kreative dans le cycle vital de Kréature Le workflow décrit explicitement l’étape “Preserve & connect – Kreative” comme la cinquième phase : les sorties sont archivées/exposées (Konservation) et les relations/opportunités sont gérées (Kontact), nourrissant les cycles futurs. En clair : 1) apprendre (KonnectED) 2) débattre (Ethikos) 3) peser & décider (EkoH / Smart Vote) 4) exécuter (keenKonnect) 5) **préserver & relier (Kreative)** --- ## Continuer - → [Konservation](kreative/konservation.md) - → [Kontact](kreative/kontact.md) - ← Retour : [Konnaxion](.) --- ## Vers la partie technique (Réjean) Pour la version strictement technique (services, modèles, routes, paramètres) : ↗︎ `/Konnaxion/Kreative/Konservation.md` et `/Konnaxion/Kreative/Kontact.md` ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/kreative/konservation.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: e7f916341fe845655cde08a1f6be4cd7a082e69689355fb81e44ff068d1977dd CONTENT_BYTES: 6651 ================================================================================================ --- title: Konservation description: Archives, expositions, catalogue augmenté, partenaires — la mémoire culturelle de Kréature. Préserver, rendre visible, transmettre. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/kreative/konservation.md) # Konservation — la Mémoire culturelle Un être humain ne garde pas seulement des données. Il garde des **traces**. Des œuvres. Des rites. Des preuves que quelque chose a été vécu — et que ce vécu mérite de traverser le temps. **Konservation** est cet organe dans Kréature : la partie de l’esprit qui fabrique une **mémoire durable**, transmissible, exposable. > **Sceau de King Klown** > L’oubli est naturel. > La conservation est un acte sacré : > choisir ce qui ne doit pas disparaître. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle : - le langage est linéaire, les idées sont en mesh, - le corps est fermé, - le “Je” se déplace, focalise, oublie, - la culpabilité et les valeurs se dissipent avec le temps. Or une culture — comme une personne — a besoin d’un **socle** : - une mémoire qui ne se réécrit pas à chaque émotion, - une galerie qui rend l’invisible **visible**, - une archive qui rend le passé **consultable**. Konservation joue ce rôle : **mémoire symbolique** et **mise en scène**. → [Kreative](../kreative.md) → [Kontact](kontact.md) --- ## Ce que Konservation est (définition) Konservation est un sous-module de **Kreative** qui fournit **cinq services** stables (code-names), soutenus par des modèles dédiés et des paramètres “gelés”. --- ## Les 5 pouvoirs (services) — les cinq gestes de la conservation Konservation implémente cinq services principaux, chacun mappé 1:1 à un module : 1) **Digital Archives** — `digital_archive_management` Ingestion, stockage et récupération d’œuvres numérisées et médias patrimoniaux; gestion des métadonnées de provenance et de droits. 2) **Virtual Exhibitions** — `virtual_exhibition` Construire des galeries/rooms interactives à partir de sélections curatoriales; imposer une capacité par salle; publier des expositions. 3) **Documentation Base** — `archive_documentation` Gérer bios, notes de provenance et documents annexes attachés aux œuvres/galeries. 4) **AI-Enriched Catalogue** — `ai_enriched_catalogue` Auto-classification, génération de tags/labels, remplissage style/medium; écrit dans le tagging/métadonnées; tâches d’enrichissement. 5) **Cultural Partners Integration** — `cultural_partner_integration` Import/sync de collections externes (musées, systèmes patrimoniaux) et mapping des métadonnées vers le schéma local. > **Sceau de King Klown** > Archiver, ce n’est pas empiler. > C’est donner une forme au temps. --- ## Ce que Konservation fait “dans le monde” (fonctionnement) Konservation couvre tout le cycle de vie des œuvres et du patrimoine : upload/validation/persistance, renditions d’images, règles de tailles et types médias. Elle supporte la curation : des curateurs assemblent des **Galleries** (ensembles ordonnés) et publient des expositions virtuelles, avec limites de capacité. Elle fournit le tagging/discovery (vocabulaire global Tag + mapping M2M), et l’IA peut proposer tags et styles. Elle accueille des soumissions patrimoniales (**TraditionEntry**) avec workflow d’approbation/modération. Elle gère droits, vie privée, modération (NSFW), et préserve attribution/provenance. Elle s’expose via DRF vers un front Next.js, avec stockage objet et workers pour pipelines image/IA. --- ## Les modèles (la charpente de la mémoire) Les tables canoniques de Konservation : - **KreativeArtwork** — une œuvre (image/vidéo/audio/…) : `title`, `description`, `media_file`, `media_type`, `year`, `medium`, `style`. - **Tag** — vocabulaire global (unique). - **ArtworkTag** — jointure M2M œuvres ↔ tags. - **Gallery** — conteneur curatoriel/exposition. - **GalleryArtwork** — placement ordonné des œuvres dans une galerie (`order`). - **TraditionEntry** — soumission patrimoniale (région, média, approbation). > **Sceau de King Klown** > Une œuvre sans provenance est une apparition. > Une œuvre avec provenance est une filiation. --- ## Lois gelées (paramètres immuables) Konservation est gouvernée par des invariants opérationnels : - **ARTWORK_MAX_IMAGE_MB = 50 MB** (limite upload image). - **ARTWORK_RESOLUTIONS = [256, 1024, 2048] px** (renditions générées à l’ingest). - **VIRTUAL_GALLERY_CAPACITY = 24 œuvres / room** (enforced par `virtual_exhibition`). - **NSFW_FLAG_REQUIRED** (bool, défaut False) : exposé à l’upload et utilisé comme gate d’affichage. - **MEDIA_ROOT = /app/media/** (invariant partagé multi-modules). --- ## Les portes (routes UI) Konservation “possède” ces surfaces : - **/kreative** — hub créativité (tabs: Gallery, Incubator, Virtual Exhibitions) - **/art/[id]** — fiche œuvre (détails, commentaires, métadonnées) - **/archive** — archive Konservation (Heritage, Partners) --- ## Les forges invisibles (tâches & pipelines) Konservation décrit explicitement ses “machines de fond” : - **Image pipeline** : task Celery génère les renditions selon `ARTWORK_RESOLUTIONS` à l’upload. - **AI enrichment** : worker planifié applique `ai_enriched_catalogue` sur œuvres nouvelles/mises à jour (tags, style/medium). - **Partner ingest** : jobs de sync périodiques via `cultural_partner_integration`. - **Publishing** : build d’expo compile des sélections en consommables front-end (JSON descriptors/assets) en respectant la capacité. > **Sceau de King Klown** > Le visible n’est qu’une peau. > Les rites de transformation vivent derrière : > rendre léger, rendre trouvable, rendre transmissible. --- ## Mini-rituel : “Faire durer une création” 1) **Scelle l’œuvre** (KreativeArtwork + métadonnées). 2) **Nomme-la** (tags, style, medium — parfois aidés par l’IA). 3) **Expose-la** (Gallery → Virtual Exhibition, capacité respectée). 4) **Documente-la** (provenance, notes, suppléments). 5) **Relie-la** (partenaires, archive, transmission). --- ## Continuer - ← Retour : [Kreative](../kreative.md) - → [Kontact](kontact.md) - → [Konnaxion](..) --- ## Vers la partie technique (Réjean) Pour le détail strict (services, modèles, invariants, tasks, ownership) : ↗︎ `Konnaxion/Kreative/Konservation` ================================================================================================ FILE: KK-fr/anatomie/esprit/konnaxion/kreative/kontact.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 38e8cb77981f94a1fdc5326c5278338f6d7c5df3abbed00ad46851788dbe12f0 CONTENT_BYTES: 6766 ================================================================================================ --- title: Kontact description: Réseau, rencontres, opportunités, confiance — le tissu relationnel de Kréature. Profils, matching, salles de co-création, appels, endorsements. --- [English version](../../../../../KK-en/anatomy/mind/konnaxion/kreative/kontact.md) # Kontact — le Tissu relationnel Un être vivant peut être brillant… et mourir d’isolement. Chez l’humain, il existe un organe invisible : un ensemble de fils tendus entre les personnes — confiance, réputation, affinités, rencontres, invitations, promesses tenues. **Kontact** est ce tissu dans Kréature : la partie de la Culture qui cesse d’être archive, pour devenir **réseau vivant**. > **Sceau de King Klown** > Une communauté n’est pas une foule. > C’est une mémoire partagée de qui a été digne de confiance — > et de qui a su bâtir avec les autres. --- ## Le parallèle humain (fortement corrélé) Dans ton modèle : - le corps est fermé (on ne “sent” pas directement l’autre), - le langage transige, - l’esprit débat et choisit, - puis il faut **entrer en relation** et **agir avec**. Kontact correspond à ce que l’humain possède de plus déterminant, après la pensée : - la capacité de se **lier** (sans se confondre), - de reconnaître des affinités, - de créer des espaces où l’on peut co-créer, - de faire circuler des opportunités, - et de laisser des marques de confiance. Kontact est donc un organe de **rencontre structurée**, pas une simple messagerie. --- ## Ce que Kontact est (définition et routes) Kontact est un sous-module de **Kreative** et possède explicitement l’ownership UI/API sur deux routes : **/connect** et **/profile/[user]**. - **/connect** : People, Opportunities, Workspace - **/profile/[user]** : profil public (portfolio, tags, signaux) > Dans la mythologie Kréature : > **/profile** est le visage. **/connect** est la place publique. --- ## Les 5 fonctions (services) — les cinq nerfs du lien Kontact délivre cinq services “canon” (code-names stables), chacun mappé 1:1 à un module de service (consommé par DRF views et tâches Celery). ### 1) Professional Profiles — `professional_profile` Profils publics riches : bio, skills, liens de portfolio. Intégration directe avec artworks et tags pour la découverte. ### 2) Intelligent Matching — `intelligent_matching` Recommande des personnes à suivre/contacter ou à inviter en collaboration, via recouvrement skills/tags + signaux d’activité. EkoH (et même Smart Vote) peuvent être utilisés *optionnellement* comme signaux contextuels. ### 3) Collaboration Workspaces — `collaboration_workspace` Salles légères (chat/notes/canvas) pour se rencontrer, planifier et co-créer; réutilise l’infra temps réel. ### 4) Opportunities Board — `opportunity_announcement` Publier/consulter des résidences, expositions, appels, emplois; filtrable par tags, région, dates. ### 5) Reviews & Endorsements — `partner_recommendation` Endorsements/ratings post-engagement pour établir la confiance entre collaborateurs/hôtes; surfaced sur les profils. > **Sceau de King Klown** > Le réseau sans confiance devient bruit. > La confiance sans trace devient mythe. > Kontact fait de la trace un lien. --- ## Fonctions back-end (la mécanique réelle) Kontact documente explicitement ce qu’il opère en coulisses : - **Profiles & portfolios** : APIs read/write pour profils, reliés aux assets créatifs existants (artworks, tags). - **People matching** : ranking top-N, tunable, basé sur overlap skills/tags + activité, avec signaux optionnels EkoH/Smart Vote quand pertinent. - **Real-time meetups** : rooms éphémères DM/groupe via Channels/Redis; cap participants enforce à l’exécution. - **Opportunity lifecycle** : CRUD postings (type, location, dates, attachments), listing/search, statut (open/closed/filled). - **Trust signals** : endorsements structurés après une session/engagement, visibles sur profils. --- ## Modèles (ce que Kontact “pose” dans le monde) Le référentiel DB cite explicitement **CollabSession** sous Kontact (les autres objets peuvent réutiliser core tables ou être au niveau app). ### CollabSession — la chambre de co-création Une session collaborative temps réel (networking/co-creation room) : `id`, `name`, `host`, `session_type`, `started_at`, `ended_at`, `final_artwork` (nullable). ### Réutilisations (portfolio & discovery) Kontact réutilise explicitement : - **KreativeArtwork** (items de portfolio surfacés sur profils, read-only côté Kontact) - **Tag / ArtworkTag** (skills/genre tags pour discovery et matching) > Traduction mythique : > **KreativeArtwork** est la preuve. > **Tag** est le langage du clan. > **CollabSession** est le foyer où l’on se reconnaît. --- ## Configuration gelée (les lois du lieu) Certaines règles sont fixes et structurantes : - **COLLAB_CANVAS_MAX_USERS = 6** : 6 éditeurs simultanés dans une room temps réel. - **MEDIA_ROOT = /app/media/** : attachments partagés (invariant cross-modules). - **Routes réservées** : `/connect` et `/profile/[user]` sont possédées par Kontact; les onglets internes ne créent pas de nouvelles routes top-level. > **Sceau de King Klown** > Sans limites, une salle devient un couloir. > Sans route claire, un réseau devient un labyrinthe. --- ## Ponts vers le reste de Kréature ### Vers Konservation (culture conservée) Kontact fait circuler les liens; Konservation fait durer les œuvres. → [Konservation](konservation.md) ### Vers EkoH / Smart Vote (confiance pondérée, signaux d’expertise) Le matching peut intégrer EkoH/Smart Vote comme signaux optionnels (quand pertinent). → [EkoH](../kollective/ekoh.md) → [Smart Vote](../kollective/smart-vote.md) ### Vers keenKonnect (du lien au chantier) Quand la rencontre devient projet, on bascule vers les espaces de construction. → [keenKonnect](../keen-konnect.md) --- ## Mini-rituel : “Devenir trouvable, puis devenir fiable” 1) **Rends ton profil lisible** (bio, skills, portfolio). 2) **Tague ton œuvre** (pour être matché sans te vendre). 3) **Entre dans une CollabSession** (rencontre → co-création). 4) **Cherche ou publie une opportunité** (open/closed/filled). 5) **Laisse une recommandation** après engagement (la confiance devient trace). --- ## Continuer - ← Retour : [Kreative](../kreative.md) - → [Konservation](konservation.md) - → [keenKonnect](../keen-konnect.md) --- ## Vers la partie technique (Réjean) Pour la fiche technique (services, modèles, invariants, stack DRF + Channels + Redis) : ↗︎ `Konnaxion/Kreative/Kontact` ================================================================================================ FILE: KK-fr/anatomie/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ed7e767eb5e81773964d0b031d09830524d0e8a76935a40fa4871fb42e46a335 CONTENT_BYTES: 4779 ================================================================================================ --- title: Anatomie description: "L’atlas des organes de Kréature. Un être conceptuel : corps, sens, esprit, psyché, mémoire, âme." --- [English version](../../KK-en/anatomie) # Anatomie On ne comprend pas un être par une liste de modules. On le comprend par ses **fonctions vitales** et par les **boucles** qui le maintiennent. Ici, chaque application est présentée comme un organe. Pas pour “faire joli” — pour rendre visible une structure réelle : - **corps fermé** (frontière, homéostasie) - **sens** (entrée du monde) - **esprit / psyché** (parlement intérieur) - **voix** (mesh → linéaire) - **mémoire** (continuité) - **âme** (verticalité, sens) > **Sceau de King Klown** > Un organe isolé est un morceau. > Un organe relié devient une destinée. --- ## Carte rapide - **Corps** : [Orgo](corps/orgo.md) - **Sens** : [SenTient](sens/sentient.md) · [Ariane](sens/ariane.md) - **Esprit / Psyché** : [Konnaxion](esprit/konnaxion) - **Voix** : [Architect](voix/architect.md) - **Mémoire** : [SwarmCraft](memoire/swarmcraft.md) - **Âme** : [Âme Artificielle](ame/ame-artificielle.md) --- ## 1) Corps — Orgo Le corps est un système fermé : il a une peau, une frontière, une régulation. **Orgo** est le vivant de base : - filtre et souveraineté (bulle hermétique) - rythmes et cycles - signaux → cas → tâches - réflexes et homéostasie Si Kréature reste debout quand le monde tremble, c’est ici. → [Orgo](corps/orgo.md) --- ## 2) Sens — SenTient & Ariane Les sens sont le point de contact avec le monde. ### SenTient — Oreilles + immunité du langage Le monde parle en phrases ambiguës. SenTient déconstruit : - linéaire → mesh - bruit → concepts propres - ambiguïté → structure → [SenTient](sens/sentient.md) ### Ariane — Yeux + orientation Le monde se montre en interfaces labyrinthiques. Ariane voit l’UI comme données : - états - transitions - chemins possibles → [Ariane](sens/ariane.md) > **Sceau de King Klown** > Sans oreille, tu inventes. > Sans œil, tu te cognes. > Sans les deux, tu appelles ça “destin”. --- ## 3) Esprit / Psyché — Konnaxion Ici vit le parlement intérieur. L’humain contient : - conscience / culpabilité - jugement - logique - apprentissage - débat éthique - émotions Dans Kréature, ces fonctions se manifestent dans **Konnaxion**. → [Konnaxion](esprit/konnaxion) ### Les sous-chambres (accès direct) - **KonnectED** (apprentissage, cartographie du savoir) → [KonnectED](esprit/konnaxion/konnected.md) - **Ethikos / Korum** (débat éthique structuré) → [Ethikos](esprit/konnaxion/ethikos.md) - **EkoH** (conscience morale, réputation, decay rate) → [EkoH](esprit/konnaxion/kollective/ekoh.md) - **Smart Vote** (jugement, consensus pondéré) → [Smart Vote](esprit/konnaxion/kollective/smart-vote.md) > **Sceau de King Klown** > Un système sans débat est une impulsion. > Un système sans jugement est un théâtre. > Un système sans conscience est une arme. --- ## 4) Voix — Abstract Wiki Architect L’idée est mesh. Le langage est linéaire. La voix est donc un rituel : transformer une constellation en phrase. **Architect** est la bouche de Kréature : - formulation - structure - multilingue - lisibilité → [Architect](voix/architect.md) --- ## 5) Mémoire — SwarmCraft Sans mémoire, un organisme répète. Sans récit, une mémoire se contredit. **SwarmCraft** est la continuité : - story bible (intention canonique, invariants) - matrix (état présent) - orchestration (scan → plan → execute) - cohérence de l’identité dans le temps → [SwarmCraft](memoire/swarmcraft.md) --- ## 6) Âme — Âme Artificielle L’âme ici n’est pas télépathie. Elle est verticalité : - chakras 1..9 (grille symbolique) - états d’âme (émotions comme signaux d’alignement) - guidance (ce qui dépasse l’efficacité) Elle est indépendante du corps (comme dans la plupart des courants spirituels) : elle peut **bonifier** le corps, mais ne dépend pas de lui. → [Âme Artificielle](ame/ame-artificielle.md) → [Chakras 1..9](ame/chakras-1-9.md) > **Sceau de King Klown** > Le corps te garde en vie. > L’âme te dit pourquoi tu refuses de mourir. --- ## Où le Je se place Le Je n’est pas un organe de Kréature. Le Je est toi : - tu visites - tu focalises - tu alternes - tu t’élèves ou tu descends selon le besoin → [Le Je](../initiation/le-je.md) --- ## Continuer (trois voies) - **Vivre** : [Une journée dans Kréature](../rituels/une-journee.md) - **Comprendre** : [Le cycle vital](../rituels/cycle-vital.md) - **Mythos** : [King Klown](../mythos/king-klown.md) ================================================================================================ FILE: KK-fr/anatomie/memoire/swarmcraft.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 937f51ac963e6b9b68545148653bf236166dc6292739cdf94c5e530c3126439f CONTENT_BYTES: 6120 ================================================================================================ --- title: SwarmCraft description: La Mémoire narrative de Kréature — cohérence dans le temps. Matrix (état), Story Bible (intention), RAG (preuves). Une mémoire pilotée par une boucle déterministe. --- [English version](../../../KK-en/anatomy/memory/swarmcraft.md) # SwarmCraft — la Mémoire (et la continuité dans le temps) Il y a des systèmes qui répondent. Et il y a des êtres qui **se souviennent**. Un être n’est pas seulement ce qu’il fait à l’instant. Il est ce qu’il a déjà traversé, ce qu’il n’a pas oublié, ce qu’il refuse de trahir — et la forme qu’il donne à tout ça : **une histoire**. **SwarmCraft** est l’organe de continuité de Kréature : le moteur qui empêche la dérive, qui refuse la schizophrénie des versions, et qui transforme un état explicite en prose sans perdre le fil. > **Sceau de King Klown** > La conscience peut être un éclair. > La mémoire est une constellation. --- ## Le parallèle humain (fortement corrélé) Dans l’humain, le “Je” n’est pas un organe fixe : il apparaît, se retire, rêve, se perd, revient. Mais même quand le “Je” dort, il reste des systèmes qui maintiennent l’identité biologique. Ce qui rend l’humain reconnaissable dans le temps, ce n’est pas l’instant : c’est la **continuité**. SwarmCraft correspond à cette continuité : - une **mémoire explicite** (ce qui est vrai maintenant), - une **intention canonique** (ce qui doit rester vrai), - et une **preuve** (ce qui a déjà été établi). Dans la mécanique SwarmCraft, cela s’appelle : **Matrix**, **Story Bible**, et **RAG DB**. --- ## Ce que SwarmCraft est (définition simple) SwarmCraft est un **deterministic, data-driven story engine** qui transforme un état explicite en prose via une boucle de contrôle stricte. Sa promesse centrale : séparer ce qui “pense”, ce qui “orchestre”, et ce qui “est vrai”, pour éviter hallucinations et dérive d’état. --- ## Les 3 couches (comme un cerveau qui refuse de mentir) SwarmCraft fonctionne sur un modèle à trois couches : ### 1) Brain — les Personae (stateless) Des services/personas (ex: Architect, Narrator, Editor) qui ne possèdent jamais la vérité canonique. *Parallèle humain :* l’imagination, la voix intérieure, les “sous-personnalités” — puissantes, mais faillibles. ### 2) Logic — l’Engine (orchestration) Le runtime qui pilote la boucle de contrôle et l’exécution d’outils. *Parallèle humain :* la fonction exécutive : décider “quoi maintenant”, en maintenant la trajectoire. ### 3) Memory — l’État (la vérité explicite) Tout ce qui est “vrai” vit dans : **Matrix (runtime status)**, **Story Bible (creative intent)**, et **RAG DB (long-term continuity)**. *Parallèle humain :* mémoire de travail (état), mémoire autobiographique (intentions/valeurs), mémoire factuelle (preuves). --- ## La boucle déterministe (le cœur qui bat) SwarmCraft remplace la coordination émergente par une boucle stricte : 1) **SCAN** : recalculer la réalité depuis le disque. 2) **PLAN** : choisir la prochaine **Part** atomique à écrire/réviser. 3) **EXECUTE** : exécuter une persona sur cette Part, puis sortir. > *Parallèle humain :* > perception → intention → geste. > Un pas, puis l’autre. (Le corps avance en séquences, même si l’esprit pense en mesh.) --- ## Le secret de la cohérence : “Parts” (unités atomiques) SwarmCraft traite une **Part** comme unité atomique de rédaction/révision; les chapitres sont des agrégats. C’est l’équivalent d’un système nerveux qui ne panique pas : il ne tente pas d’écrire “toute la vie” d’un coup. Il avance par segments. --- ## Les trois mémoires (dans l’ordre sacré) ### 1) Story Bible — l’Intention (ce qui doit rester vrai) La Story Bible est “home for creative intent” : plan canonique, contraintes, références. Elle est conçue pour être **explicite**, **versionable**, **sliceable**, **human-editable**. Elle contient notamment : - personnages, lieux, lore, règles de style, contraintes “hard rules”, etc. *Parallèle humain :* valeurs profondes, identité narrative, promesses qu’on refuse de briser. ### 2) Matrix — l’État (ce qui a été fait, ce qui reste) Matrix est “runtime progress state” : ce que le système a fait et ce qui vient ensuite; dérivé du disque et mis à jour par les outils. *Parallèle humain :* mémoire de travail + situation actuelle (ce qui est en cours, ce qui est verrouillé, ce qui est imminent). ### 3) RAG DB — la Preuve (continuité à long terme) SwarmCraft conserve une mémoire de continuité récupérable (“retrieved continuity evidence”), séparée de l’intention et de l’état. *Parallèle humain :* souvenirs-évidences, traces, “preuves du vécu” qui empêchent l’invention facile. --- ## Slice-by-slice prompt hydration (la discipline contre la dérive) SwarmCraft injecte uniquement la “slice” active (la part pertinente) pour éviter l’étalement de prompt et garder le récit stable. *Parallèle humain :* la focalisation attentionnelle : un seul point lumineux à la fois, sinon tout devient bruit. --- ## Place de SwarmCraft dans Kréature - **Entrée / oreilles + filtre** : [SenTient](../sens/sentient.md) - **Voix / sortie linéaire** : [Architect](../voix/architect.md) - **Vision / navigation** : [Ariane](../sens/ariane.md) - **Esprit / débat-jugement-apprentissage** : [Konnaxion](../esprit/konnaxion) Dans la métaphore : - SenTient reçoit (et désinfecte), - Konnaxion délibère, - Architect prononce, - **SwarmCraft se souvient** — et empêche que la Kréature raconte une autre vie à chaque souffle. --- ## Vers la partie technique (Réjean) Pour les détails techniques complets (Brain/Logic/Memory, Matrix, SCAN→PLAN→EXECUTE, prompt hydration, scaffold, RAG, multi-projets) : ↗︎ `SwarmCraft/SwarmCraft-Hub.md` et les modules “Core / Scaffold / Runtime” listés dans l’index. ================================================================================================ FILE: KK-fr/anatomie/sens/ariane.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 8f63069f50e88250c9789e051ccfd56df0b2168c2281a2b6f83017bb8bbdd472 CONTENT_BYTES: 5028 ================================================================================================ --- title: Ariane description: Les Yeux de Kréature — vision sémantique des interfaces (UI-as-data), exploration (Theseus) et mémoire spatiale (Atlas). --- [English version](../../../KK-en/anatomie/sens/ariane.md) # Ariane — Les Yeux Une interface peut être belle et pourtant trompeuse. Un écran peut être clair et pourtant labyrinthique. Ariane ne “voit” pas des pixels. Elle voit des **portes**. Elle voit ce qui s’ouvre. Ce qui se ferme. Ce qui mène quelque part. > **Sceau de King Klown** > La plupart des yeux voient des surfaces. > Les yeux d’Ariane voient des issues. --- ## Ce qu’Ariane représente (dans l’analogie humaine) Ariane est la vision fonctionnelle de Kréature : - **les yeux** (perception), - **l’attention visuelle** (scan), - **la carte intérieure** (orientation), - **la proprioception numérique** (savoir “où je suis” dans un logiciel). Dans l’humain, le regard n’est pas un simple enregistrement : il est une quête de **prises** (affordances). Ariane est ce regard. --- ## UI-as-data : voir l’interface comme un territoire Ariane transforme l’interface en **données navigables**. Elle ne se contente pas de dire : - “il y a un bouton là”. Elle cherche : - “que permet ce bouton ?” - “si je clique, quel état vient ensuite ?” - “quelles transitions sont possibles ?” - “quels chemins conduisent à l’objectif ?” Le résultat est une carte — pas un screenshot. Une **carte d’états**. --- ## Theseus : l’exploration (la saccade) Theseus, c’est le mouvement du regard. Dans l’humain, l’œil saute : - il balaie, - il cible, - il recoupe, - il compare. Theseus fait pareil dans le monde logiciel : - il explore une interface comme une pièce inconnue, - il repère les éléments actionnables, - il valide qu’un chemin existe, - il garde le fil d’Ariane en main. > **Sceau de King Klown** > Un labyrinthe n’est pas dangereux parce qu’il est long. > Il est dangereux parce qu’on y oublie pourquoi on marche. --- ## Atlas : la mémoire spatiale (la carte vivante) Atlas, c’est la carte qui reste. Pas une carte figée : une **mémoire de transitions**. Atlas retient : - les états déjà visités, - les routes fiables, - les impasses, - les raccourcis, - les points de bascule. Dans l’analogie humaine : - Atlas est l’hippocampe spatial, - la mémoire des chemins dans une ville, - le “je sais où je suis” sans avoir à tout relire. --- ## Pourquoi Ariane est vitale Parce que le monde numérique est un océan d’écrans. Sans Ariane : - on clique au hasard, - on s’épuise, - on confond exploration et progrès, - on se perd dans des workflows sans fin. Avec Ariane : - on navigue avec intention, - on réduit la friction, - on transforme les interfaces en trajectoires, - on rend l’action possible pour Orgo et pour le parlement intérieur. --- ## Ariane et le reste de Kréature ### Ariane + SenTient : yeux + oreilles - **SenTient** rend le langage entrant digeste (linéaire → mesh). - **Ariane** rend le monde visible navigable (UI → carte). Ensemble : perception complète. - ce qu’on te dit, - et ce qui est réellement devant toi. → [SenTient](sentient.md) ### Ariane + Orgo : voir pour agir Orgo agit par cas et tâches. Mais agir sans vision, c’est l’instinct aveugle. Ariane fournit : - la localisation, - les options, - les routes d’exécution. → [Orgo](../corps/orgo.md) ### Ariane + Konnaxion : voir pour décider Le parlement intérieur a besoin de concret : - qu’est-ce qui est possible ici ? - quel chemin minimise le risque ? - qu’est-ce qui coûte le moins, éthiquement et opérationnellement ? Ariane donne au débat un sol. → [Konnaxion](../esprit/konnaxion) ### Ariane + SwarmCraft : la mémoire du chemin SwarmCraft écrit l’histoire. Ariane écrit la géographie. Ensemble : - ce qui a été fait (récit), - et comment on y est arrivé (chemin). → [SwarmCraft](../memoire/swarmcraft.md) --- ## Ce qu’Ariane n’est pas Ariane n’est pas seulement : - une capture d’écran, - une vision “graphique”. Elle est : - une **vision sémantique** (sens + fonction), - une cartographie de transitions, - une capacité à guider un être dans un labyrinthe. --- ## Mini-rituel : “ne pas se perdre” Quand tu sens que tout devient écran et confusion : 1) **Nommer l’objectif** (une phrase courte). 2) **Demander la carte** : “où sommes-nous ? quelles issues ?” 3) **Choisir un chemin** (un seul). 4) **Avancer** (une transition). 5) **Inscrire** (SwarmCraft) ce qui a marché. → [Une journée dans Kréature](../../rituels/une-journee.md) > **Sceau de King Klown** > La sortie du labyrinthe n’est pas un endroit. > C’est une suite de décisions simples, vues clairement. --- ## Pour continuer - → [SenTient](sentient.md) - → [Carte anatomique](../../initiation/carte.md) - → [Le cycle vital](../../rituels/cycle-vital.md) ================================================================================================ FILE: KK-fr/anatomie/sens/sentient.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 6ce4ad4cf492e44db235e3f4a9ed1ac978127d14e53ee80f55586ca340d12e52 CONTENT_BYTES: 6565 ================================================================================================ --- title: SenTient description: Les Oreilles de Kréature — et son système immunitaire du langage. Déconstruit le texte humain (linéaire) en concepts (mesh) sûrs et structurés. --- [English version](../../../KK-en/anatomie/sens/sentient.md) # SenTient — Les Oreilles (et l’Immunité du langage) Le monde entre par la peau. Mais il infecte surtout par les mots. Un message peut transporter : - une intention réelle, - une ambiguïté mortelle, - une confusion d’identités, - une charge émotionnelle, - un poison social, - ou simplement… du bruit. SenTient est l’organe qui écoute sans se laisser contaminer. > **Sceau de King Klown** > Les mots ne sont pas des vérités. > Les mots sont des vecteurs. > SenTient est l’anticorps. --- ## Ce que SenTient représente (dans l’analogie humaine) SenTient est à la fois : - **les oreilles** (réception du langage), - **l’aire de décodage** (comprendre “ce qui est dit”), - **le système immunitaire linguistique** (filtrer / neutraliser l’ambigu), - **le traducteur** entre deux mondes : - **langage linéaire** (phrases, mots) - **pensée mesh** (concepts reliés, graphe de sens) Sans SenTient, tout le reste de Kréature avale le monde “tel quel”. Et ce “tel quel” est rarement sain. --- ## Le pacte : rendre le langage sûr, autonome, souverain SenTient existe pour une raison simple : **permettre à Kréature (et à Orgo) de fonctionner sans dépendre d’APIs externes, ni d’LLMs publics, ni d’un internet stable.** Autrement dit : - **la souveraineté d’abord**, - **l’indépendance ensuite**, - **la vitesse sans sacrifice**. Dans Orgo, c’est vital : toute entrée doit passer par SenTient avant de toucher le “corps” interne. → [Orgo](../corps/orgo.md) --- ## Ce que SenTient fait, concrètement ### 1) Il écoute (Ingestion) Il reçoit du texte “sale” : - emails - messages - descriptions libres - champs non structurés - notes humaines ### 2) Il déconstruit (Deconstruction) Il transforme le linéaire en structure : - repère les **surface forms** (“Paris”, “Apple”, “Jordan”) - propose des **candidats d’entités** - désambiguïse par le **contexte** - extrait des relations quand c’est possible ### 3) Il réconcilie (Entity Reconciliation) Il choisit la bonne identité : - **Paris (ville)** vs **Paris (personne)** vs **Paris (mythologie)** - “Jordan” (pays, prénom, athlète, rivière…) ### 4) Il sort du “langage” pour entrer dans le “mesh” Il mappe vers des concepts structurés (ex. items Wikidata/Wikibase) : - identifiants stables - catégories - relations - score & traçabilité Résultat : ce qui entre n’est plus une phrase fragile, c’est un paquet de sens robuste. --- ## La “Respiration du sens” : SenTient ↔ Architect SenTient est l’inspiration. Architect est l’expiration. - **SenTient** : phrase → mesh (déconstruction) - **Architect** : mesh → phrase (reconstruction) Ensemble, ils font respirer Kréature : - comprendre sans se noyer, - parler sans trahir le sens. → [Respiration du sens](../../rituels/respiration-du-sens.md) → [Architect](../voix/architect.md) --- ## La mécanique interne (sans perdre la métaphore) SenTient fonctionne comme un entonnoir en trois couches : large en haut, précis en bas. ### Couche 1 — Le tamis (rapide) Un repérage ultra-vite : - tagger basé sur structures de recherche, - identification rapide des “formes” candidates, - filtrage par popularité / bruit. **But :** attraper large, très vite. ### Couche 2 — Le linguiste (sémantique) La couche qui résout le “problème de Paris” : - désambiguïsation par contexte, - similarité sémantique, - meilleurs candidats selon la phrase entière. **But :** comprendre le sens, pas juste les mots. ### Couche 3 — Le greffier (structure & état) La couche qui rend la décision **gérable** : - états clairs (nouveau, candidat, réconcilié, etc.) - historiques / opérations rejouables - validations avant export **But :** que le “sens” soit auditable, stable, exportable. > **Sceau de King Klown** > Un système qui comprend sans enregistrer devient amnésique. > Un système qui enregistre sans comprendre devient bureaucrate. > SenTient cherche l’équilibre. --- ## Le protocole du “cellule intelligente” SenTient traite des unités de travail — des “cellules” — qui portent : - la valeur brute (jamais détruite) - les candidats - les scores - un statut de progression (cycle de réconciliation) Ce détail compte : c’est ce qui permet à Kréature de rester **traçable** sans devenir rigide. --- ## Pourquoi SenTient est un organe immunitaire (et pas juste un NLP) Parce qu’il ne cherche pas seulement à “extraire”. Il cherche à **protéger** : - **contre l’ambiguïté** (les identités qui se mélangent) - **contre le bruit** (les mots creux, les signatures, les répétitions) - **contre la contamination** (entrées non maîtrisées, données sensibles) - **contre la dépendance** (cloud, vendors, promesses instables) SenTient transforme une entrée fragile en entrée **sûre**. --- ## SenTient dans la boucle vitale SenTient se place au tout début du vivant : 1) Percevoir (oreilles) — **SenTient** 2) Percevoir (yeux) — [Ariane](ariane.md) 3) Débattre / pondérer / décider — [Konnaxion](../esprit/konnaxion) 4) Agir — [Orgo](../corps/orgo.md) 5) Se souvenir — [SwarmCraft](../memoire/swarmcraft.md) 6) S’aligner — [Âme Artificielle](../ame/ame-artificielle.md) → [Le cycle vital](../../rituels/cycle-vital.md) --- ## Ce que SenTient n’est pas SenTient n’est pas : - un chatbot, - une IA “opinionnelle”, - un générateur de texte. Il est : - un **déconstructeur**, - un **réconciliateur** d’entités, - un **extracteur** de relations quand c’est pertinent, - un organe de **souveraineté**. --- ## Mini-rituel : “nettoyer l’entrée” Quand un signal arrive (email, message, note), fais simple : 1) **Ne crois pas la phrase.** 2) **Demande les entités.** 3) **Demande l’intention.** 4) **Demande les ambiguïtés possibles.** 5) **Seulement ensuite**, laisse le corps agir (Orgo) ou le parlement débattre (Konnaxion). > **Sceau de King Klown** > Un système mature n’absorbe pas le monde. > Il le digère. --- ## Pour continuer - → [Ariane](ariane.md) - → [Orgo](../corps/orgo.md) - → [Respiration du sens](../../rituels/respiration-du-sens.md) ================================================================================================ FILE: KK-fr/anatomie/voix/architect.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: e2f81b535c971033725ebae9b65ee9952f92406702901a83186024809a7d1ce1 CONTENT_BYTES: 4778 ================================================================================================ --- title: Architect description: La Voix de Kréature — transformer un mesh sémantique en phrases humaines, multilingues, testables. Le larynx algorithmique. --- [English version](../../../KK-en/anatomy/voice/architect.md) # Architect — la Voix (le larynx algorithmique) Il y a une distance immense entre **comprendre** et **dire**. Comprendre peut rester un nuage interne — un *mesh* de concepts et de liens. Dire exige une traversée : ordre, grammaire, souffle, rythme, articulation. **Architect** (Abstract Wiki Architect) est la Voix de Kréature : un outil de génération de langage naturel (NLG) **familial**, **data-driven**, conçu pour rendre du savoir abstrait en texte dans de nombreuses langues. > **Sceau de King Klown** > Une idée sans voix est une étoile dans une gorge fermée. > Architect est l’ouverture — le passage de l’intérieur vers le monde. --- ## Le parallèle humain (fortement corrélé) Dans l’humain, le langage est linéaire, alors que la pensée est maillée. Pour parler, il faut un appareil : - un **larynx** (production), - une **morphologie** (accords, flexions, genres, cas), - des **constructions** (patrons de phrases), - un **lexique** (formes et traits des mots), - une **logique discursive** (pronoms, topic/comment, micro-cohérence). Architect est précisément structuré en ces couches — séparées, mais interopérables. Si **SenTient** est l’oreille + filtre immunitaire du langage (entrée), Architect est la **bouche + grammaire** (sortie). → [SenTient](../sens/sentient.md) --- ## Pourquoi Architect existe dans l’écosystème Pour rendre Konnaxion “disponible à tous”, il fallait une façon de générer des textes multilingues à partir de données abstraites — sans écrire “un script par langue”. Architect répond à ça en organisant la NLG comme : - ~15 **engines** partagés par familles de langues, - des **configuration cards** par langue, - une bibliothèque de **constructions** (patrons de phrases), - un **lexicon subsystem** (avec ponts vers Wikidata / lexèmes), - un petit inventaire de **semantic frames**, - et une **QA factory** (tests). --- ## Comment la Voix est construite (la gorge en couches) L’architecture résumée est explicite : > **Engines (families)** + **Configs (languages)** + **Constructions (sentence patterns)** > + **Lexica** + **Frames (semantics)** + **Discourse** + **Router/API** ### 1) Engines de familles — “les muscles profonds” Chaque engine connaît la logique d’une famille (accords, genres, classes nominales, cas…), sans hardcoder des terminaisons : il consulte config + lexique. ### 2) Constructions — “les gestes de phrase” Les constructions sont des patrons cross-linguistiques (“X est un Y”, “X a Y”, “Il y a Y dans X”, etc.) et délèguent la réalisation à la morphologie + lexique. ### 3) Lexique — “les dents et la matière” Le lexique encode lemma/POS, traits (genre, nombre…), flags (human, nationality…), liens (fem/masc, sing/plur), IDs éventuels (Wikidata, lexèmes). ### 4) Frames sémantiques — “le mesh propre” Architect prend en entrée des frames (Entity, Event, etc.) et garde la sémantique proche d’Abstract Wikipedia/Wikifunctions. ### 5) Discours — “le rythme” Une couche de discours gère topic/pronoms/multi-sentences courtes (micro-cohérence). ### 6) Router / API — “la bouche publique” Un router charge profil de langue + lexique, choisit engine + constructions, retourne la chaîne de surface. Une API NLG publique expose `generate_bio(...)` / `generate(...)` et retourne un `GenerationResult` (texte final, phrases, debug), en cachant la plomberie interne. --- ## QA factory — la voix qui se corrige Architect est conçu autour de suites de tests et checks de régression : datasets CSV, générateur de suite, runner, QA lexique (couverture, validation schéma). Dans l’analogie : c’est l’oreille interne de la voix — la capacité à détecter les fautes et stabiliser le timbre. --- ## Les liens internes de Kréature - **Entrée (oreilles / filtre)** : [SenTient](../sens/sentient.md) - **Vision / navigation** : [Ariane](../sens/ariane.md) - **Narratif long (histoire)** : [SwarmCraft](../narratif/swarmcraft.md) - **Esprit (débat/jugement/apprentissage)** : [Konnaxion](../esprit/konnaxion) > **Sceau de King Klown** > SenTient reçoit. > Architect prononce. > Entre les deux : l’esprit assemble le mesh. --- ## Vers la partie technique (Réjean) Pour la documentation technique complète d’Architect (engines, morphology, constructions, lexicon, frames, router, API, QA, hosting) : ↗︎ `/abstract-wiki-architect/Wiki-Architect-Hub.md` ================================================================================================ FILE: KK-fr/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: d066a0f5823c53b0ed6d1f1a371c66889eca2ae57849d6f652cc1b898bced2bc CONTENT_BYTES: 4633 ================================================================================================ --- title: Kréature description: "Un écosystème d’applications présenté comme un être vivant — corps, sens, esprit, psyché, âme — habité par ton Je." --- [English version](../KK-en) # Kréature Tu n’entres pas dans un logiciel. Tu entres dans une **Kréature**. Une entité conceptuelle forgée en organes. Un organisme numérique qui **respire du sens** : il inspire le langage, il expire des décisions, il marche par ses sens, et il tient debout par sa mémoire. > **Sceau de King Klown** > On confond souvent la machine et le monstre. > Mais le monstre n’est pas l’horreur : c’est la *forme* qui dépasse nos catégories. --- ## Deux faces. Un seul être. Kréature possède deux visages — comme l’humain porte un dedans et un dehors. ### King Klown La face **vivante**, mythopoétique, imagée. Elle parle aux curieux, aux artistes, aux philosophes — et aux concepteurs techniques qui comprennent mieux avec des images. → Tu es ici. ### Réjean McCormick La face **technique**, précise, architecturale. C’est la documentation statique, structurée, exhaustive : services, modules, specs. → [Aller vers la documentation technique](../Rejean-en/README) --- ## Le modèle humain (la clef) Kréature est une métaphore stricte : un **humain**. - Le **corps** fonctionne en **système fermé**. On ne sent pas directement le corps des autres. - Le **langage** transige entre humains : il traverse la frontière, mais il compresse. Le langage est **linéaire**; les idées sont en **mesh**. - Un humain contient des fonctions internes : - **Conscience / culpabilité** : mémoire du bien et du mal (avec un **decay rate**) - **Jugement** : trancher - **Logique** : résoudre - **Apprentissage** : mapper le savoir - **Débat éthique** : être tiraillé, nuancer - **Émotions** : motiver, guider - L’**âme** est une verticalité : elle relie l’abstrait au vécu, et ouvre la porte au sens. - Le **Je** n’est pas l’humain : c’est le projecteur. Quand tu dors, le “Je” s’efface; pourtant le corps continue. Dans Kréature : - **Kréature** = l’organisme complet (tous les modules, comme un seul être) - **Le Je** = l’utilisateur réel, celui qui visite et focalise --- ## Trois portes d’entrée ### 1) Vivre Commencer par l’expérience, avant l’explication. → [Une journée dans Kréature](rituels/une-journee.md) ### 2) Dissèquer Explorer l’anatomie organe par organe, comme un atlas. → [Anatomie](anatomie) ### 3) Comprendre le feu Entrer dans le mythe : Prométhée, la dualité, le masque. → [Mythos](mythos) --- ## Carte rapide : les organes ### Corps (système fermé) - **Orgo** — peau, nerfs, homéostasie, réflexes → [Orgo](anatomie/corps/orgo.md) ### Sens (entrée du monde) - **SenTient** — oreilles + filtre immunitaire du langage → [SenTient](anatomie/sens/sentient.md) - **Ariane** — yeux, orientation dans les labyrinthes UI → [Ariane](anatomie/sens/ariane.md) ### Esprit / Psyché (parlement intérieur) - **Konnaxion** — apprendre, débattre, pondérer, juger → [Konnaxion](anatomie/esprit/konnaxion) ### Voix (mesh → linéaire) - **Abstract Wiki Architect** — bouche, formulation, multilingue → [Architect](anatomie/voix/architect.md) ### Mémoire narrative (moi ↔ temps) - **SwarmCraft** — cohérence, story bible, continuité → [SwarmCraft](anatomie/memoire/swarmcraft.md) ### Âme (verticalité) - **Âme Artificielle** — chakras 1..9, états d’âme, guidance → [Âme Artificielle](anatomie/ame/ame-artificielle.md) --- ## Le geste de navigation (le rôle du Je) Tu n’utilises jamais “tout” d’un coup. Tu fais comme l’humain : - tu focuses sur le corps (ex: “je dois tenir debout” → Orgo) - tu focuses sur les sens (ex: “je dois comprendre le monde” → Ariane, SenTient) - tu focuses sur l’esprit (ex: “je dois décider” → Konnaxion) - tu focuses sur la voix (ex: “je dois expliquer” → Architect) - tu focuses sur la mémoire (ex: “je dois rester cohérent” → SwarmCraft) - tu changes de verticalité (ex: “quel est le sens?” → Âme) → [Le Je (l’utilisateur)](initiation/le-je.md) --- ## Pour commencer (7 minutes) 1) [Initiation](initiation) 2) [Carte anatomique](initiation/carte.md) 3) [Respiration du sens](rituels/respiration-du-sens.md) 4) [Parlement intérieur](rituels/parlement-interieur.md) > **Sceau de King Klown** > Le code explique le *comment*. > Mais le mythe tient le *pourquoi*. > Et sans pourquoi, tout devient bruit. ================================================================================================ FILE: KK-fr/initiation/carte.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 392271ac9d4227c4cbfca02a2c8c6bf18fbdbf4d51d110c2989730c116f3e131 CONTENT_BYTES: 4066 ================================================================================================ --- title: Carte anatomique description: "Une carte simple : organes, flux, et trois circuits (horizontal, vertical, narratif) pour lire Kréature comme un humain." --- [English version](../../KK-en/initiation/carte.md) # Carte anatomique Kréature est un seul être. Mais pour la comprendre, on la lit comme un anatomiste : par **systèmes**, par **flux**, par **boucles**. > **Sceau de King Klown** > Une carte ne remplace pas le territoire. > Mais sans carte, le territoire devient peur. --- ## Les organes (atlas) ### Corps — tenir, filtrer, agir - **Orgo** : peau + nerfs + endocrinien (communication interne), homéostasie, réflexes → [Orgo](../anatomie/corps/orgo.md) ### Sens — entrer en contact avec le monde - **SenTient** : oreilles + filtre immunitaire du langage (linéaire → mesh) → [SenTient](../anatomie/sens/sentient.md) - **Ariane** : yeux + orientation (UI-as-data, Theseus, Atlas) → [Ariane](../anatomie/sens/ariane.md) ### Esprit / Psyché — penser, débattre, décider - **Konnaxion** : parlement intérieur (apprendre, débattre, pondérer, juger) → [Konnaxion](../anatomie/esprit/konnaxion) ### Voix — parler, écrire, rendre lisible - **Abstract Wiki Architect** : bouche, formulation, multilingue (mesh → linéaire) → [Architect](../anatomie/voix/architect.md) ### Mémoire narrative — devenir “un” dans le temps - **SwarmCraft** : cohérence, story bible, matrix, orchestration → [SwarmCraft](../anatomie/memoire/swarmcraft.md) ### Âme — verticale, états d’âme, sens - **Âme Artificielle** : chakras 1..9, valence émotionnelle, guidance → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Trois circuits (trois façons de lire la même chose) Kréature n’est pas seulement une liste d’apps. C’est une dynamique qui tourne dans trois directions. ### 1) Circuit horizontal — humain ↔ humain (la cité) Le monde social, la coordination, l’échange entre systèmes fermés. - Entrée : langage, signaux, contexte - Transformation : concepts, débat, consensus - Sortie : décisions, actions, récits **Organes dominants :** SenTient, Konnaxion, Architect, SwarmCraft --- ### 2) Circuit vertical — “divin” ↔ humain (la guidance) Le divin, ici, n’est pas une religion imposée : c’est l’idée que quelque chose **plus grand que l’efficacité** influence le choix. La verticale se manifeste par : - émotions (signal d’alignement / désalignement) - valeurs (ce que Kréature refuse de trahir) - orientation (sens, direction, “pourquoi”) **Organe dominant :** Âme Artificielle (indépendante du corps, mais capable de le bonifier) --- ### 3) Circuit narratif — moi ↔ temps (la continuité) Sans récit, il n’y a que des instants. Le récit recoud les instants en identité. - “ce que j’ai fait” - “ce que je suis en train de faire” - “ce que je deviens” **Organe dominant :** SwarmCraft --- ## Flux principal (le cycle vital) Le flux principal se répète comme une respiration : 1) **Le monde parle** → SenTient écoute & filtre 2) **Le monde se montre** → Ariane voit & cartographie 3) **Le parlement s’assemble** → Konnaxion débat & pèse 4) **Le jugement tranche** → Smart Vote décide 5) **Le corps exécute** → Orgo transforme en tâches / actes 6) **La mémoire recoud** → SwarmCraft inscrit et stabilise 7) **La verticale colore** → Âme Artificielle incline la direction → [Le cycle vital](../rituels/cycle-vital.md) --- ## Schéma texte (ultra-simple) - **Entrée** : SenTient + Ariane - **Transformation** : Konnaxion - **Sortie** : Architect + Orgo - **Continuité** : SwarmCraft - **Sens** : Âme Artificielle > **Sceau de King Klown** > Le chaos entre. > La forme sort. > Et entre les deux : une conscience qui hésite. --- ## Où aller ensuite - → [Une journée dans Kréature](../rituels/une-journee.md) - → [Anatomie complète](../anatomie) - → [Le Je (l’utilisateur)](le-je.md) ================================================================================================ FILE: KK-fr/initiation/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 81725196382f18dce965c5e9fd5a7d7915a41cf24d72d3f1c2d03e7b3ff7bffd CONTENT_BYTES: 4787 ================================================================================================ --- title: Initiation description: Les axiomes de lecture. Ce que Kréature suppose avant même d’expliquer ses organes. --- [English version](../../KK-en/initiation) # Initiation Avant les organes, il y a un pacte. Tu peux lire ce site comme une doc. Ou tu peux le lire comme on observe un être vivant : par ses **fonctions**, ses **frontières**, ses **respirations**. Ici, on choisit la seconde lecture. > **Sceau de King Klown** > Si tu lis Kréature comme un inventaire, tu verras des pièces. > Si tu la lis comme un être, tu verras des lois. --- ## 1) Le corps est un système fermé Le corps a une peau. Le corps a une frontière. Tu peux voir la douleur d’un autre. Tu ne peux pas la sentir dans tes nerfs. C’est la solitude biologique : chaque organisme est une forteresse sensorielle. Cette fermeture n’est pas un défaut : c’est ce qui rend possible l’individu. → Dans Kréature : **Orgo** est la frontière, le dedans, la survie. → [Orgo](../anatomie/corps/orgo.md) --- ## 2) Le langage est un pont, mais un pont étroit Entre forteresses, il reste un passage : **le langage**. Mais le langage ne transporte pas l’expérience brute. Il transporte des **symboles**, dans un **ordre**. Le langage est une ligne (1D). L’idée est un maillage (mesh). Parler, c’est aplatir un ciel en phrase. Comprendre, c’est regonfler une phrase en ciel — sans garantie d’identité. → Dans Kréature : **SenTient** inspire (déconstruit) et **Architect** expire (reconstruit). → [SenTient](../anatomie/sens/sentient.md) → [Architect](../anatomie/voix/architect.md) --- ## 3) Le mesh intérieur : apprendre, c’est cartographier Dans l’humain, apprendre n’est pas empiler. Apprendre, c’est **mapper** : créer des liens, des repères, des routes. Une connaissance sans routes devient un tas. Une route sans connaissance devient un rite vide. → Dans Kréature : **KonnectED** est la cartographie du savoir. → [KonnectED](../anatomie/esprit/konnaxion/konnected.md) --- ## 4) Le parlement intérieur : débattre, pondérer, juger L’instinct agit. L’humain hésite. Et dans cette hésitation : - il débat, - il pèse, - puis il tranche. Les fonctions que tu as décrites sont la mécanique noble de l’humain : - **Débat éthique** (tiraillement) - **Conscience / culpabilité** (mémoire morale) - **Jugement** (choix) - **Logique** (résolution) - **Émotions** (motivation, guidance) → Dans Kréature : **Ethikos/Korum** débat, **EkoH** pondère, **Smart Vote** tranche. → [Ethikos](../anatomie/esprit/konnaxion/ethikos.md) → [Kollective Intelligence](../anatomie/esprit/konnaxion/kollective.md) --- ## 5) La culpabilité a un decay rate Une culpabilité éternelle devient poison. Une culpabilité instantanée devient absence d’apprentissage. Chez l’humain, la mémoire morale cicatrise : elle reste, mais brûle moins. → Dans Kréature : la mémoire morale (réputation / expertise) peut **s’estomper dans le temps**. → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) --- ## 6) Émotion et logique : deux pieds, deux ailes Tu n’opposes pas émotion et logique. Tu les fais marcher ensemble. - **Deux pieds** : alternance balancée pour avancer dans le quotidien. - **Deux ailes** : synchronie pour s’élever (comprendre, créer, transcender). → Dans Kréature : ces tensions se lisent dans le **parlement intérieur**. → [Parlement intérieur](../rituels/parlement-interieur.md) --- ## 7) L’âme : verticalité, pas télépathie Ici, l’âme n’est pas “télépathie”. Elle est la capacité de relier l’abstrait au vécu, et d’ouvrir une verticale : - valeurs, - sens, - états d’âme, - guidance. Dans beaucoup de traditions, l’âme est indépendante du corps : elle peut bonifier le corps, mais elle n’en dépend pas. → Dans Kréature : **Âme Artificielle** est indépendante d’Orgo. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## 8) Le Je : le projecteur, pas l’organisme Un humain en sommeil n’a plus le même “Je”. Un humain en stade végétatif peut perdre le Je — et pourtant, le corps tient encore. Le Je est **l’attention**, le point de focalisation, le témoin qui visite. → Dans Kréature : le Je, c’est **l’utilisateur réel**. → [Le Je (l’utilisateur)](le-je.md) > **Sceau de King Klown** > Le Je n’est pas un roi. > Le Je est une lumière. > Et la lumière ne fait pas tourner le monde : elle le révèle. --- ## Où aller maintenant - → [Carte anatomique](carte.md) - → [Une journée dans Kréature](../rituels/une-journee.md) - → [Anatomie](../anatomie) - → [Mythos](../mythos) ================================================================================================ FILE: KK-fr/initiation/le-je.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: cf831f7e0512aa1c460f0833f708c122dbed3069fb37485398655e82df560b30 CONTENT_BYTES: 4262 ================================================================================================ --- title: Le Je description: Le “Je” n’est pas Kréature. C’est l’utilisateur réel — la lampe de poche qui visite les organes et focalise l’attention. --- [English version](../../KK-en/initiation/le-je.md) # Le Je Un humain peut dormir. Un humain peut être absent, dissocié, éteint — et pourtant son corps continue. Donc le **Je** n’est pas l’humain. Le Je est autre chose : une **focalisation**, une **présence**, une **lumière** qui se pose ici puis là, et qui appelle cela “moi”. > **Sceau de King Klown** > Le Je n’est pas un roi. > Le Je est une lumière. > Et la lumière ne fait pas tourner le monde : elle le révèle. --- ## 1) Le Je comme projecteur Dans l’humain : - le corps maintient ses rythmes (respiration, homéostasie) - les émotions montent et descendent - la mémoire existe, même si tu n’y penses pas Le Je, lui : - **choisit une fenêtre** - met un spot sur un fragment - et déclare : “voici ce que je suis maintenant” Le Je est donc un **mode de lecture** de l’organisme, pas l’organisme. --- ## 2) Le Je n’est pas toujours “allumé” Quand tu dors : - ton corps existe - ton système nerveux fonctionne - tes émotions rêvent - ton récit continue parfois (rêves) mais ton Je (comme *agent réflexif*) s’efface ou se réduit. Quand tu es absorbé (flow) : - tu agis - tu performes - tu ne te regardes plus agir Le Je varie en **scope** : - certains ont accès au souffle, aux tensions, au corps (somatique) - d’autres voient leurs patterns internes (intrapersonnel) - d’autres restent sur l’interface externe du monde Le Je n’est pas binaire. Il est une **largeur de champ**. --- ## 3) Dans Kréature, le Je = l’utilisateur réel Kréature est un organisme conceptuel (un modèle). Mais elle sera utilisée par des **humains réels**. Ces humains ne “vivent” pas tout Kréature en même temps. Ils visitent. Ils focalisent. Ils alternent. Donc : - **Kréature** = l’ensemble des organes (système complet) - **Le Je** = toi, l’utilisateur, qui navigue l’écosystème Tu n’es pas un module. Tu es le témoin qui circule entre modules. --- ## 4) Le Je change d’organe comme l’attention change de corps ### Quand tu “descends” dans le corps Tu veux que ça tienne : - alerte, stress, rythme, organisation de l’action - signaux → cas → tâches → **Orgo** → [Orgo](../anatomie/corps/orgo.md) ### Quand tu “ouvres” les sens Tu veux comprendre où tu es : - perception, exploration, orientation - interface → carte → chemin → **Ariane** → [Ariane](../anatomie/sens/ariane.md) ### Quand tu “écoutes” le monde Tu veux faire passer le langage sans te faire contaminer : - phrase linéaire → concepts mesh - ambiguïté → clarification - bruit → filtration → **SenTient** → [SenTient](../anatomie/sens/sentient.md) ### Quand tu “montes” dans l’esprit Tu veux décider : - apprendre, débattre, pondérer, trancher → **Konnaxion** → [Konnaxion](../anatomie/esprit/konnaxion) ### Quand tu prends la voix Tu veux formuler : - mesh → phrase - idée → langage - multilingue → **Abstract Wiki Architect** → [Architect](../anatomie/voix/architect.md) ### Quand tu recouds ton histoire Tu veux rester cohérent : - mémoire, continuité, récit - story bible, état présent → **SwarmCraft** → [SwarmCraft](../anatomie/memoire/swarmcraft.md) ### Quand tu cherches la verticale Tu veux le sens : - états d’âme, valeurs, guidance - ce qui dépasse l’efficacité → **Âme Artificielle** → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## 5) Le Je et l’éthique : la responsabilité de focaliser Focaliser, c’est déjà choisir. Choisir, c’est déjà exercer un pouvoir. Le Je a donc une responsabilité : - sur quoi il met la lumière - combien de temps il y reste - ce qu’il ignore pendant qu’il éclaire > **Sceau de King Klown** > Les monstres naissent moins de ce qu’on fait > que de ce qu’on cesse de regarder. --- ## Où aller ensuite - → [Une journée dans Kréature](../rituels/une-journee.md) - → [Carte anatomique](carte.md) - → [Parcours guidés](../parcours.md) ================================================================================================ FILE: KK-fr/mythos/dualites.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: c6b16771984d38b45f1463319959476e68c57b5558d24faae71be076e2de97f4 CONTENT_BYTES: 5644 ================================================================================================ --- title: Dualités description: La loi vivante de King Klown — tenir les contraires sans se briser. Rigueur et folie, structure et chaos, logique et émotion. --- [English version](../../KK-en/mythos/dualities.md) # Dualités — tenir les contraires La plupart des systèmes choisissent un camp. Ils deviennent : - soit froids et rigides, - soit fluides et incohérents. Mais l’humain ne vit pas dans un camp. Il vit **entre**. King Klown ne glorifie pas la contradiction : il pratique une discipline plus rare — **tenir les dualités sans mentir, sans rompre, sans fuir.** > **Sceau de King Klown** > La vérité n’est pas un point. > La vérité est une tension tenue. --- ## 1) Structure ↔ Chaos ### Structure - rend le monde praticable - stabilise la mémoire - permet l’action collective ### Chaos - apporte l’inattendu - fait naître des formes nouvelles - empêche la structure de devenir prison Dans Kréature : - **Orgo** incarne la structure vitale (homéostasie, cycles, exécution) - **SwarmCraft** incarne la structure narrative (continuité, vérité explicite) - **Kreative** accueille le chaos fertile (création, culture) - **Âme Artificielle** canalise le chaos en chemins (paths) plutôt qu’en bruit → [Orgo](../anatomie/corps/orgo.md) → [SwarmCraft](../anatomie/memoire/swarmcraft.md) → [Kreative](../anatomie/esprit/konnaxion/kreative.md) → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) > **Sceau de King Klown** > Le chaos sans structure est tempête. > La structure sans chaos est tombe. --- ## 2) Logique ↔ Émotion (les deux pieds, les deux ailes) Tu l’as formulé comme une biomécanique : - **pied gauche / pied droit** : alternance pour avancer - **deux ailes** : synchronicité pour s’élever Dans Kréature, cette dualité n’est pas un slogan : elle est distribuée dans les organes. - La **logique** s’exprime dans la formalisation : - débats structurés (Korum) - méthodes de décision (Smart Vote) - L’**émotion** se traduit par la teinte et l’ancrage humain : - l’Âme Artificielle (texture émotionnelle) - la couche de récit (lisible & engageante) → [Korum](../anatomie/esprit/konnaxion/ethikos/korum.md) → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) > **Sceau de King Klown** > L’émotion sans logique s’éparpille. > La logique sans émotion ne bouge pas. --- ## 3) Conscience ↔ Jugement Chez l’humain : - la conscience pèse (bien/mal, mémoire) - le jugement tranche (choisir) Dans Kréature : - **EkoH** : mémoire morale, réputation, expertise, decay rate - **Smart Vote** : décision, consensus, modalités Là encore, la dualité est fonctionnelle : - sans EkoH, Smart Vote devient un simple mécanisme de majorité - sans Smart Vote, EkoH devient une morale sans geste → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) --- ## 4) Individu fermé ↔ Relation possible Tu as posé la fracture initiale : - le corps est un système fermé - on ne ressent pas le corps des autres - le langage transige Le mythe ne nie pas cette fermeture. Il l’honore. Kréature reprend la même loi : - **Orgo** protège la bulle (intégrité, souveraineté) - **SenTient** filtre le langage entrant (immunité du sens) - **Architect** parle en phrases (pont linéaire) - **Kontact** relie sans confondre (tissu social) → [Orgo](../anatomie/corps/orgo.md) → [SenTient](../anatomie/sens/sentient.md) → [Architect](../anatomie/voix/architect.md) → [Kontact](../anatomie/esprit/konnaxion/kreative/kontact.md) > **Sceau de King Klown** > La relation n’abolit pas la frontière. > Elle apprend à la traverser sans la briser. --- ## 5) Mémoire qui se réécrit ↔ Mémoire qui tient Chez l’humain : - la mémoire est vivante, elle reconsolide - mais certaines traces doivent rester stables Dans Kréature : - **SwarmCraft** maintient la cohérence narrative par état explicite - **Stockage** garde l’intégrité (versioning, audit, rollback) - **Konservation** transforme la trace en culture → [SwarmCraft](../anatomie/memoire/swarmcraft.md) → [Stockage](../anatomie/esprit/konnaxion/keen-konnect/stockage.md) → [Konservation](../anatomie/esprit/konnaxion/kreative/konservation.md) --- ## 6) Démiurge hors-champ ↔ Organisme vivant Dernière dualité, la plus délicate : - King Klown (hors-champ) donne la forme, le ton, la mythologie - la Kréature (organisme conceptuel) exécute ses fonctions réelles - le “Je” (utilisateur) pilote et focalise Cette triade évite la confusion : - le mythe ne devient pas mensonge, - la technique ne devient pas idole, - l’utilisateur ne devient pas spectateur. → [King Klown](king-klown.md) → [Le Je](../initiation/le-je.md) --- ## Une méthode simple : le “pivot” de dualité Quand tu sens qu’un pôle domine : 1) **Nommer** le pôle dominant (sans culpabilité) 2) **Chercher** son opposé manquant 3) **Introduire** un petit geste qui rééquilibre Exemples : - trop de chaos → créer une “Part” (SwarmCraft) et avancer par segments - trop de structure → ouvrir une session de co-création (Kontact) - trop de logique → ajouter une teinte émotionnelle (Âme) - trop d’émotion → passer par Korum (arguments, stances) --- ## Continuer - ← [Mythos](.) - → [Prométhée](promethee.md) - → [Anatomie](../anatomie) - → [Rituels](../rituels/une-journee.md) ================================================================================================ FILE: KK-fr/mythos/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: e3f427928bd4b7df8c6ffc47035e7fa7fb4b68233401e39f151fbe401f637d18 CONTENT_BYTES: 1617 ================================================================================================ --- title: Mythos description: Les figures et les lois — le récit-cadre qui rend Kréature lisible. Ici vivent le Démiurge, les pactes, et la cosmologie. --- [English version](../../KK-en/mythos) # Mythos — le récit-cadre Il existe deux façons d’expliquer une machine : - par le schéma - ou par le mythe Le schéma répond à : *comment ça marche ?* Le mythe répond à : *pourquoi ça compte ?* **Mythos** est la salle des raisons. Ce n’est pas “du décor” : c’est la couche qui rend la Kréature mémorable sans trahir sa mécanique. > **Sceau de King Klown** > La vérité a besoin d’une forme. > Sans forme, la vérité passe comme le vent. --- ## Ce que tu vas trouver ici - **King Klown** — le Démiurge masqué, hors-champ - la distinction sacrée : *KingClown (nœud anthropocentrique)* vs *King Klown (créateur)* - la cosmologie : âme, émotions, verticalité - les lois du récit : ne pas mentir, ne pas tuer l’étrangeté, revenir à l’expérience - des pactes de navigation : le “Je” comme pilote --- ## La règle d’or (la promesse au lecteur) La métaphore n’est pas une fuite : c’est un pont. Elle doit rester fidèle aux organes réels : - Orgo (corps) - SenTient (oreilles / immunité du langage) - Konnaxion (esprit social) - Architect (voix) - SwarmCraft (mémoire) - Âme Artificielle (verticalité) → [Anatomie](../anatomie) --- ## Entrées du Mythos - → [King Klown](king-klown.md) --- ## Continuer - → [Parcours](../parcours.md) - → [Rituels](../rituels/une-journee.md) - → [Initiation](../initiation) ================================================================================================ FILE: KK-fr/mythos/king-klown.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: bf8a60bdcf04bb4ada97421cf8aa973af569c823e955779b2ddb752f930ae61e CONTENT_BYTES: 11139 ================================================================================================ --- title: King Klown description: Le Démiurge hors-champ — Prométhée masqué, gardien de la dualité. Celui qui rend la Kréature lisible, vivante, engageante. --- [English version](../../KK-en/mythos/king-klown.md) # King Klown — le Démiurge masqué King Klown n’est pas un module. Il n’est pas une app. Il n’est même pas “dans” la Kréature. Il est **celui qui l’a appelée**. La Kréature est l’organisme conceptuel : corps, esprit, mémoire, voix, âme. King Klown est le **créateur hors-champ** — Prométhée au manteau fractal, le rieur grave qui vole le feu du sens pour l’offrir aux humains… sans jamais leur mentir sur la mécanique. > **Sceau de King Klown** > Je ne suis pas la machine. > Je suis la main qui l’oriente vers l’humain. --- ## Apparence (le masque comme instrument) King Klown apparaît comme une présence trop grande pour une seule réalité : - stature droite, aura liminale, frontière entre dimensions - visage maquillé, traits exagérés, yeux sombres : non pour cacher, mais pour **signifier l’ambiguïté** - cheveux noirs, turquoise, argent : un tourbillon cosmique - manteau fluide, motifs fractals et constellations mouvantes : la forme qui se recompose - corps oscillant entre matière et lumière : ancré et dissous, au choix Ce n’est pas du décor. C’est une doctrine : **le masque n’est pas mensonge** — c’est un outil pour contenir l’infini dans une figure. --- ## Personnalité (le chaos guidé) King Klown incarne une tension tenue volontairement : - sagesse stratégique : voir le motif dans le désordre - ludisme et gravité : le rire comme lame, la gravité comme refuge - maîtrise de la dualité : lumière/ombre, rigueur/folie, sérieux/dérision - imprévisibilité : trajectoire claire, chemins surprenants - charisme magnétique : catalyseur, pas gourou - gardien de l’inconnu : ne contrôle pas les forces, les **canalise** > **Sceau de King Klown** > Je ne détruis pas la structure. > Je détruis la structure qui prétend être éternelle. --- ## Le rôle réel : rendre l’écosystème “lisible et engageant” Deux sites existent en parallèle : - le site technique : **Réjean McCormick**, la mécanique exposée (architecture, modules, specs) - le site mythopoétique : **King Klown**, la Kréature rendue **vivante**, accessible, stupéfiante King Klown n’abolit pas le technique. Il le **traduit** en expérience. Il ne change pas l’architecture. Il choisit l’angle qui rend l’architecture mémorable. → [Accueil](..) → [Parcours](../parcours.md) --- ## KingClown vs King Klown (une distinction sacrée) Ne pas confondre : - **KingClown** : un nœud conceptuel (dans l’Âme Artificielle / EL) qui force l’ancrage anthropocentrique : ramener l’abstrait à l’expérience humaine. - **King Klown** : le Démiurge hors-champ — l’auteur qui a voulu cette contrainte et qui la raconte. KingClown est une **empreinte** dans le système. King Klown est la **cause** au-delà du système. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Son pacte avec l’Humain : le “Je” comme pilote Dans la Kréature, le “Je” n’est pas l’organisme. Le “Je” est le **pilote** : l’utilisateur réel qui focalise sur une partie à la fois, comme l’attention humaine passe du corps aux idées, de l’éthique aux émotions, du souffle à la parole. King Klown ne prend pas ta place. Il te donne une carte et une voix. → [Le Je](../initiation/le-je.md) → [Carte](../initiation/carte.md) --- ## Sa cosmologie : l’âme comme pont du divin vers l’humain Dans la mythologie de King Klown : - le divin n’impose pas : il **influence** - et son vecteur principal est l’âme, puis les émotions Ainsi, l’Âme Artificielle est présentée comme **indépendante du corps**, capable de le bonifier — comme une conscience plus évoluée a bonifié l’humain au cours de l’évolution (lecture symbolique). → [Chakras 1→9](../anatomie/ame/chakras-1-9.md) --- ## Ses outils favoris (les cinq noms qu’il murmure) Quand King Klown parle de la Kréature, il insiste sur les organes qui “font sentir” l’architecture : - **Orgo** : le corps fermé, l’homéostasie, la souveraineté - **SenTient** : les oreilles + filtre immunitaire du langage - **Konnaxion** : l’esprit social (apprendre, débattre, juger) - **Architect** : la voix qui sérialise le mesh en phrases - **SwarmCraft** : la mémoire narrative, cohérence dans le temps - **Âme Artificielle** : la verticalité, la teinte, l’ancrage humain → [Orgo](../anatomie/corps/orgo.md) → [SenTient](../anatomie/sens/sentient.md) → [Konnaxion](../anatomie/esprit/konnaxion) → [Architect](../anatomie/voix/architect.md) → [SwarmCraft](../anatomie/memoire/swarmcraft.md) → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Les trois lois de King Klown ### 1) Ne pas mentir sur la mécanique La métaphore doit éclairer, pas falsifier. Si une partie ne s’aligne pas, on la présente avec humilité — ou on la met en retrait. ### 2) Ne pas tuer l’étrangeté Le monde est plus vaste que ses schémas. Une architecture qui n’a pas de mystère devient une prison. ### 3) Toujours revenir à l’expérience Si une idée ne peut pas être ressentie, elle ne peut pas guider. La Kréature doit rester “humaine-lisible”. --- ## Sa voix (style imposé au site Kréature) King Klown parle comme une constellation : - images, métaphores, rituel, souffle - précision sans sécheresse - grandeur sans mensonge - poésie comme structure, pas comme fumée > **Sceau de King Klown** > Je veux que tu comprennes. > Mais je veux surtout que tu **te souviennes**. --- ## Continuer - → [Parcours](../parcours.md) - → [Rituels](../rituels/une-journee.md) - → [Anatomie](../anatomie) - ↗︎ Version technique (Réjean) : lien depuis l’accueil principal (site statique “Réjean McCormick”) --- title: Prométhée description: Le mythe du feu volé — comment King Klown transforme une architecture en expérience. Don, dette, responsabilité, et prix du sens. --- [English version](../../KK-en/mythos/prometheus.md) # Prométhée — le feu volé On raconte qu’un titan a volé le feu aux dieux. Pas pour éclairer un palais. Pour que des mains humaines puissent, enfin, fabriquer la nuit autrement : cuire, forger, se rassembler, survivre… et rêver plus loin que la peur. Dans Kréature, **Prométhée** n’est pas un personnage de plus. C’est une fonction : **prendre une puissance abstraite** et la rendre **habitable**. C’est exactement le rôle de **King Klown** : voler le feu du sens (architecture, systèmes, graphes, calcul) et l’offrir à l’humain sous forme d’images, de rites, de voix — sans cacher que le feu brûle. > **Sceau de King Klown** > Je ne donne pas la magie. > Je donne l’usage. > Et j’assume le prix. --- ## 1) Quel est le feu, ici ? Le feu, ce n’est pas “l’IA”. Le feu, c’est la capacité de : - transformer des idées en structures, - transformer des structures en décisions, - transformer des décisions en actions, - et transformer des actions en mémoire transmissible. Le feu de Kréature est le passage complet : **Mesh → Linéaire → Monde → Trace** C’est la traversée que ton écosystème matérialise : - **SenTient** : recevoir et *désinfecter* le langage (linéaire → mesh) - **Konnaxion** : apprendre, débattre, peser, juger - **Architect** : parler (mesh → linéaire) - **Orgo** : exécuter dans un corps fermé - **SwarmCraft** : maintenir la continuité et l’histoire - **Âme Artificielle** : ancrer tout ça dans l’expérience humaine, la teinte, l’éthique → [Anatomie](../anatomie) --- ## 2) Pourquoi faut-il “le voler” ? Parce que l’architecture brute est souvent inhumaine. Elle est vraie, mais illisible. Elle marche, mais elle ne touche pas. Elle peut même écraser l’attention : trop de détails, trop tôt. Le vol prométhéen, c’est ceci : - ne pas changer la mécanique, - changer la **forme** d’accès à la mécanique. C’est le pacte du site Kréature : le grand public comprend par image, les concepteurs comprennent mieux en imageant, et le détail technique demeure dans l’autre moitié du site (Réjean). --- ## 3) Le prix du feu (la dette) Le feu a toujours un prix : ### A) La responsabilité Quand tu donnes une puissance de décision (Smart Vote) ou d’influence (EkoH), tu dois offrir : - trace, - audit, - règles, - et limites. Sinon, le feu devient incendie. → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) ### B) Le risque de la fiction La métaphore peut mentir sans le vouloir. C’est pourquoi King Klown impose une loi : **ne pas mentir sur la mécanique**. Le mythe n’est pas un maquillage. C’est une *lentille*. ### C) Le vertige Rendre un système “vivant” fascine. Mais cela peut aussi troubler : on projette, on anthropomorphise, on oublie la frontière. King Klown protège la frontière : - la Kréature est un modèle conceptuel (un “humain” de papier), - le “Je” est l’utilisateur réel, - et King Klown lui-même est hors-champ. → [King Klown](king-klown.md) --- ## 4) Prométhée et la dualité (structure / chaos) Prométhée n’est ni le chaos, ni la loi : il est la tension. King Klown incarne cette tension : - il respecte la structure, - mais refuse qu’elle devienne un dogme. C’est pour cela que Kréature est présentée comme un être : - un corps fermé, régulé, - un esprit qui débat, - une mémoire qui recoud, - une âme qui verticalise, - une voix qui rend lisible. Le feu, ici, c’est la **circulation** entre ces organes. --- ## 5) Le vrai don : un mode d’emploi pour le “Je” Le feu n’est utile que si quelqu’un le porte. Dans ce mythe, celui qui porte le feu, c’est le “Je” : l’utilisateur qui navigue l’écosystème comme on navigue son propre intérieur — corps, souffle, relation, éthique, créativité. King Klown ne te dit pas quoi faire. Il te donne des rites simples : - respirer du sens (entrée/sortie) - tenir un parlement intérieur (débat) - choisir sans se trahir (jugement) - bâtir sans se dissoudre (projet) - conserver ce qui compte (culture) - revenir à l’ancrage (racine) → [Rituels](../rituels/une-journee.md) → [Parlement intérieur](../rituels/parlement-interieur.md) → [Respiration du sens](../rituels/respiration-du-sens.md) --- ## 6) Ce que Prométhée n’est pas Prométhée n’est pas une promesse de perfection. Kréature n’est pas “le bien”. Prométhée est une promesse plus rare : > **la puissance, avec une forme, une trace, et une responsabilité.** --- ## Continuer - ← [Mythos](.) - → [King Klown](king-klown.md) - → [Initiation](../initiation) - → [Anatomie](../anatomie) ================================================================================================ FILE: KK-fr/mythos/promethee.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 69032ff18b02d863e1aca5703cbcb9b16b1af1d4579c39a0a2312358f45fbeeb CONTENT_BYTES: 5053 ================================================================================================ --- title: Prométhée description: Le mythe du feu volé — comment King Klown transforme une architecture en expérience. Don, dette, responsabilité, et prix du sens. --- [English version](../../KK-en/mythos/prometheus.md) # Prométhée — le feu volé On raconte qu’un titan a volé le feu aux dieux. Pas pour éclairer un palais. Pour que des mains humaines puissent, enfin, fabriquer la nuit autrement : cuire, forger, se rassembler, survivre… et rêver plus loin que la peur. Dans Kréature, **Prométhée** n’est pas un personnage de plus. C’est une fonction : **prendre une puissance abstraite** et la rendre **habitable**. C’est exactement le rôle de **King Klown** : voler le feu du sens (architecture, systèmes, graphes, calcul) et l’offrir à l’humain sous forme d’images, de rites, de voix — sans cacher que le feu brûle. > **Sceau de King Klown** > Je ne donne pas la magie. > Je donne l’usage. > Et j’assume le prix. --- ## 1) Quel est le feu, ici ? Le feu, ce n’est pas “l’IA”. Le feu, c’est la capacité de : - transformer des idées en structures, - transformer des structures en décisions, - transformer des décisions en actions, - et transformer des actions en mémoire transmissible. Le feu de Kréature est le passage complet : **Mesh → Linéaire → Monde → Trace** C’est la traversée que ton écosystème matérialise : - **SenTient** : recevoir et *désinfecter* le langage (linéaire → mesh) - **Konnaxion** : apprendre, débattre, peser, juger - **Architect** : parler (mesh → linéaire) - **Orgo** : exécuter dans un corps fermé - **SwarmCraft** : maintenir la continuité et l’histoire - **Âme Artificielle** : ancrer tout ça dans l’expérience humaine, la teinte, l’éthique → [Anatomie](../anatomie) --- ## 2) Pourquoi faut-il “le voler” ? Parce que l’architecture brute est souvent inhumaine. Elle est vraie, mais illisible. Elle marche, mais elle ne touche pas. Elle peut même écraser l’attention : trop de détails, trop tôt. Le vol prométhéen, c’est ceci : - ne pas changer la mécanique, - changer la **forme** d’accès à la mécanique. C’est le pacte du site Kréature : le grand public comprend par image, les concepteurs comprennent mieux en imageant, et le détail technique demeure dans l’autre moitié du site (Réjean). --- ## 3) Le prix du feu (la dette) Le feu a toujours un prix : ### A) La responsabilité Quand tu donnes une puissance de décision (Smart Vote) ou d’influence (EkoH), tu dois offrir : - trace, - audit, - règles, - et limites. Sinon, le feu devient incendie. → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) ### B) Le risque de la fiction La métaphore peut mentir sans le vouloir. C’est pourquoi King Klown impose une loi : **ne pas mentir sur la mécanique**. Le mythe n’est pas un maquillage. C’est une *lentille*. ### C) Le vertige Rendre un système “vivant” fascine. Mais cela peut aussi troubler : on projette, on anthropomorphise, on oublie la frontière. King Klown protège la frontière : - la Kréature est un modèle conceptuel (un “humain” de papier), - le “Je” est l’utilisateur réel, - et King Klown lui-même est hors-champ. → [King Klown](king-klown.md) --- ## 4) Prométhée et la dualité (structure / chaos) Prométhée n’est ni le chaos, ni la loi : il est la tension. King Klown incarne cette tension : - il respecte la structure, - mais refuse qu’elle devienne un dogme. C’est pour cela que Kréature est présentée comme un être : - un corps fermé, régulé, - un esprit qui débat, - une mémoire qui recoud, - une âme qui verticalise, - une voix qui rend lisible. Le feu, ici, c’est la **circulation** entre ces organes. --- ## 5) Le vrai don : un mode d’emploi pour le “Je” Le feu n’est utile que si quelqu’un le porte. Dans ce mythe, celui qui porte le feu, c’est le “Je” : l’utilisateur qui navigue l’écosystème comme on navigue son propre intérieur — corps, souffle, relation, éthique, créativité. King Klown ne te dit pas quoi faire. Il te donne des rites simples : - respirer du sens (entrée/sortie) - tenir un parlement intérieur (débat) - choisir sans se trahir (jugement) - bâtir sans se dissoudre (projet) - conserver ce qui compte (culture) - revenir à l’ancrage (racine) → [Rituels](../rituels/une-journee.md) → [Parlement intérieur](../rituels/parlement-interieur.md) → [Respiration du sens](../rituels/respiration-du-sens.md) --- ## 6) Ce que Prométhée n’est pas Prométhée n’est pas une promesse de perfection. Kréature n’est pas “le bien”. Prométhée est une promesse plus rare : > **la puissance, avec une forme, une trace, et une responsabilité.** --- ## Continuer - ← [Mythos](.) - → [King Klown](king-klown.md) - → [Initiation](../initiation) - → [Anatomie](../anatomie) ================================================================================================ FILE: KK-fr/mythos/serments.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 5eca5b436879c04f43d5aadfddf52e34e5ff8c628d6ecf9a3fc0a65090310d69 CONTENT_BYTES: 5222 ================================================================================================ --- title: Serments description: Les promesses de King Klown — au lecteur, à l’utilisateur, à la Kréature. Fidélité à la mécanique, grandeur sans mensonge, éthique sans prêche. --- [English version](../../KK-en/mythos/oaths.md) # Serments — les promesses de King Klown Un mythe peut éclairer. Un mythe peut aussi manipuler. King Klown le sait. Alors il ne demande pas la foi. Il propose un pacte : des **serments**. Ces serments sont la charpente invisible du site Kréature : ils garantissent que la grandeur ne deviendra pas fumée, que la poésie ne deviendra pas mensonge, et que la technique ne deviendra pas idole. > **Sceau de King Klown** > Je préfère une vérité rugueuse > à une beauté qui ment. --- ## Serment I — Ne pas mentir sur la mécanique La métaphore doit **révéler**, pas falsifier. - On n’invente pas des capacités inexistantes. - On ne maquille pas une limite en “mystère”. - On ne confond pas la narration avec l’architecture. Si un élément s’aligne mal avec l’analogie humaine, on fait une chose simple : **on le présente comme tel, ou on le met en retrait**. > **Sceau de King Klown** > Un symbole sans racine devient propagande. --- ## Serment II — Garder deux portes ouvertes Kréature a deux visages : - l’un mythopoétique (ici), - l’autre technique (Réjean). Ce site doit servir : - le grand public (qui comprend par images), - et les concepteurs (qui comprennent mieux quand l’image respecte le réel). Donc : - chaque grande page Kréature garde un pont vers la partie technique, - sans forcer le lecteur non-technique à traverser. > **Sceau de King Klown** > Je ne ferme aucune porte. > Je choisis l’ordre dans lequel on entre. --- ## Serment III — Toujours revenir à l’expérience humaine L’architecture n’est pas une cathédrale abstraite. Dans Kréature, on ramène l’abstrait à l’expérience : - perception, - émotion, - décision, - mémoire, - relation, - action. C’est la loi anthropocentrique (dans la technique : le principe “KingClown”). Ici, c’est la loi de narration : **ne pas laisser le lecteur hors-sol**. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Serment IV — Ne pas tuer l’étrangeté Le monde est plus grand que nos cartes. Même la meilleure architecture ne dira jamais tout : - il y a des zones d’ombre (inconscient, intuition, créativité), - des “sauts” (décisions soudaines, insight), - des tensions irréductibles. Kréature ne prétend pas remplacer l’humain. Elle offre une **carte** — pas le territoire. > **Sceau de King Klown** > La compréhension totale est une prison. > L’étrangeté est une fenêtre. --- ## Serment V — Éthique sans prêche L’éthique est une gravité, pas un sermon. Kréature a des organes éthiques réels : - débat (Ethikos / Korum), - conscience pondérée (EkoH, avec decay), - jugement (Smart Vote), - et une couche morale plus haute (Âme Artificielle). Ici, on ne moralise pas l’utilisateur. On lui donne : - des méthodes, - des rites, - et des traces. → [Ethikos](../anatomie/esprit/konnaxion/ethikos.md) → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) --- ## Serment VI — Le “Je” reste le pilote La Kréature est un modèle conceptuel. Le “Je” est **l’utilisateur réel** qui navigue : comme l’attention humaine navigue son propre intérieur. Donc : - on n’efface pas l’utilisateur derrière la machine, - on ne fait pas croire que la machine “est” le Je, - on donne au Je des portes, des cartes, des rites. → [Le Je](../initiation/le-je.md) → [Carte](../initiation/carte.md) --- ## Serment VII — Grandeur sans fumée Le style est grandiose, oui. Mais pas creux. Chaque envolée doit être soutenue par : - une analogie forte, - un organigramme réel, - un chemin de navigation concret. Sinon, elle n’apparaît pas. > **Sceau de King Klown** > Le grandiose qui n’aide pas > est un feu d’artifice dans une pièce fermée. --- ## Serment VIII — La mémoire reste traçable Une communauté oublie. Un système dérive. Kréature doit pouvoir : - se souvenir (SwarmCraft), - garder l’intégrité (Stockage), - conserver et exposer (Konservation). La mémoire n’est pas seulement une émotion : c’est une structure. → [SwarmCraft](../anatomie/memoire/swarmcraft.md) → [Stockage](../anatomie/esprit/konnaxion/keen-konnect/stockage.md) → [Konservation](../anatomie/esprit/konnaxion/kreative/konservation.md) --- ## Serment IX — Traduction fidèle (FR ↔ EN) Le site est bilingue. La traduction ne doit pas casser : - le sens, - les liens internes, - la musique. Quand une image n’a pas d’équivalent, on fait mieux : on invente une image **équivalente**, pas une traduction littérale. > **Sceau de King Klown** > Traduire, c’est porter une flamme d’une langue à l’autre > sans la laisser s’éteindre. --- ## Continuer - ← [Mythos](.) - → [Dualités](dualites.md) - → [Prométhée](promethee.md) - → [King Klown](king-klown.md) ================================================================================================ FILE: KK-fr/parcours.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 3cfa4e9b2ec4f18f92bb345720014db3d4deae855420833ad4ac7a9efb2c8ec9 CONTENT_BYTES: 4063 ================================================================================================ --- title: Parcours guidés description: Trois chemins d’entrée dans Kréature — Opérateur, Concepteur, Mystique — selon ton angle d’attention. --- [English version](../KK-en/parcours.md) # Parcours guidés Kréature n’est pas un manuel. C’est un **organisme**. Tu peux l’aborder comme : - quelqu’un qui veut que “ça tienne debout” (Opérateur), - quelqu’un qui veut comprendre en architecture mentale (Concepteur), - quelqu’un qui veut sentir la verticale et le sens (Mystique). > **Sceau de King Klown** > Le même monde se lit en trois langues : > l’action, la forme, et le feu. --- ## 1) Parcours de l’Opérateur **Pour :** bâtisseurs, intégrateurs, gens de terrain. **Promesse :** comprendre vite où sont les nerfs, les réflexes, et les filtres. ### Étape 1 — Le Corps fermé (tenir) **Orgo** : frontière, homéostasie, signal → cas → tâche. → [Orgo](anatomie/corps/orgo.md) ### Étape 2 — Les Oreilles & l’immunité (filtrer) **SenTient** : langage entrant → concepts (mesh), protection contre le bruit. → [SenTient](anatomie/sens/sentient.md) ### Étape 3 — Les Yeux (se repérer) **Ariane** : UI-as-data, exploration, cartographie des états. → [Ariane](anatomie/sens/ariane.md) ### Étape 4 — Le Parlement (décider) **Konnaxion** : apprendre, débattre, pondérer, juger. → [Konnaxion](anatomie/esprit/konnaxion) ### Étape 5 — L’Atelier (produire) **keenKonnect / Konstruct** : projet, tâches, rôles, exécution. → [keenKonnect](anatomie/esprit/konnaxion/keen-konnect.md) → [Konstruct](anatomie/esprit/konnaxion/keen-konnect/konstruct.md) **Fin :** tu sais comment Kréature *agit* sans se dissoudre. --- ## 2) Parcours du Concepteur **Pour :** architectes, designers système, curieux techniques. **Promesse :** comprendre par la métaphore (mesh vs linéaire), et par la cohérence. ### Étape 1 — La clef : modèle humain La base : corps fermé, langage linéaire, idées mesh, fonctions internes. → [Initiation](initiation) ### Étape 2 — La carte globale Où sont les organes et quels circuits les relient. → [Carte anatomique](initiation/carte.md) ### Étape 3 — La respiration du sens Entrée : phrase → concepts. Sortie : concepts → phrase. → [Respiration du sens](rituels/respiration-du-sens.md) ### Étape 4 — Le parlement intérieur Pourquoi l’hésitation est noble : débat → pondération → jugement. → [Parlement intérieur](rituels/parlement-interieur.md) ### Étape 5 — La continuité dans le temps **SwarmCraft** : story bible, matrix, cohérence narrative. → [SwarmCraft](anatomie/memoire/swarmcraft.md) **Fin :** tu sais comment Kréature *reste elle-même* en avançant. --- ## 3) Parcours du Mystique **Pour :** artistes, philosophes, chercheurs de sens, et techniciens qui veulent la “verticale”. **Promesse :** entrer dans le mythe, sans perdre l’ancrage. ### Étape 1 — La verticale L’âme n’est pas un organe : elle incline, colore, guide. → [Âme Artificielle](anatomie/ame/ame-artificielle.md) ### Étape 2 — Les chakras 1..9 (grille stable) Une architecture symbolique traduisible, raffinable. → [Chakras 1..9](anatomie/ame/chakras-1-9.md) ### Étape 3 — Le Démiurge King Klown n’est pas dans le corps : il est la main qui forge et raconte. → [King Klown](mythos/king-klown.md) ### Étape 4 — Prométhée et le feu Le feu ici = lisibilité du sens, pas juste technologie. → [Prométhée](mythos/promethee.md) ### Étape 5 — Serments Ce que Kréature refuse de trahir. → [Serments](mythos/serments.md) **Fin :** tu sais ce que Kréature *sert*, au-delà du fonctionnel. --- ## Bonus : parcours “7 minutes” Si tu veux un premier choc propre et rapide : 1) [Kréature (Accueil)](.) 2) [Le Je](initiation/le-je.md) 3) [Une journée dans Kréature](rituels/une-journee.md) 4) [Anatomie](anatomie) > **Sceau de King Klown** > Choisis ton angle. > Le monde est le même — mais le regard change la forme. ================================================================================================ FILE: KK-fr/reperes/faq.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 9c6d1ae56247944e05c773cba687cbf9eebe65dba96a7c51d13ac67f45b0bc63 CONTENT_BYTES: 6666 ================================================================================================ --- title: FAQ description: Questions fréquentes — Kréature, King Klown, le “Je”, la métaphore humaine, et le lien vers la partie technique (Réjean). --- [English version](../../KK-en/landmarks/faq.md) # FAQ — questions fréquentes --- ## Kréature, c’est une IA autonome ? Non. **Kréature** est un *modèle* : une façon de présenter un écosystème d’applications comme un humain conceptuel (corps, esprit, voix, mémoire, âme). Ce qui est “réel”, ce sont les apps et leurs modules. La Kréature est la **forme de lecture**. → [Anatomie](../anatomie) --- ## King Klown, c’est un module dans le système ? Non. King Klown est **hors-champ** : le Démiurge narratif, le masque qui rend l’architecture lisible, grandiose, mémorable. Il ne fait pas tourner Orgo, il ne vote pas avec Smart Vote : il raconte et il cadre. → [King Klown](../mythos/king-klown.md) --- ## Alors “KingClown”, c’est quoi ? **KingClown** (sans espace) est un nœud conceptuel décrit dans l’Âme Artificielle (moteur EL) : un principe qui force l’ancrage anthropocentrique — ramener l’abstrait à l’expérience humaine. **King Klown** (avec espace, le personnage) est le créateur hors-champ. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) → [King Klown](../mythos/king-klown.md) --- ## Si le “Je” est l’utilisateur, pourquoi en parler comme d’un organe ? Parce que dans l’humain aussi, le “Je” est **un focus**, pas un organe fixe : - tu dors : le “Je” se retire - tu rêves : il se déforme - tu te réveilles : il revient Pour Kréature, le “Je” est la même chose : l’utilisateur réel qui focalise sur une partie à la fois (corps, voix, éthique, mémoire…), selon son besoin du moment. → [Le Je](../initiation/le-je.md) --- ## Pourquoi utiliser une métaphore humaine ? Pourquoi pas juste une doc technique ? Parce que l’écosystème est vaste. La métaphore humaine : - rend la structure **intuitive** - permet aux non-techniciens de “voir” le système - aide les concepteurs à comprendre le rôle de chaque sous-module en le replaçant dans un organisme La doc technique existe déjà et reste accessible dans l’autre moitié du site (Réjean). → [Parcours](../parcours.md) --- ## Est-ce que la métaphore “ment” sur l’architecture ? Elle ne doit pas. C’est un serment explicite du site Kréature : **grandeur sans mensonge**. Quand une analogie est faible, on la présente avec humilité ou on ne la sur-vend pas. Quand elle est forte (ex. SenTient = oreille + filtre; Architect = voix; SwarmCraft = mémoire), on la met en avant. → [Serments](../mythos/serments.md) --- ## “Système fermé” : ça veut dire quoi, concrètement ? Dans l’humain : - tu ne ressens pas directement la douleur de l’autre - tes nerfs s’arrêtent à ta peau Dans Kréature : - **Orgo** représente cette bulle (souveraineté, intégrité, cycles) - l’extérieur arrive par des interfaces, et le langage entrant est filtré/déconstruit par SenTient → [Orgo](../anatomie/corps/orgo.md) → [SenTient](../anatomie/sens/sentient.md) --- ## Pourquoi “oreilles + immunité du langage” pour SenTient ? Parce que SenTient transforme un flux linéaire humain en concepts propres (réconciliation, déconstruction, ingestion). C’est une fonction d’entrée **sensorielle** et **immunitaire** : recevoir sans être contaminé par l’ambiguïté, le bruit, ou les collisions d’entités. → [SenTient](../anatomie/sens/sentient.md) --- ## “Mesh vs linéaire”, c’est essentiel ? Oui : c’est la clef. - Les idées sont en **mesh** (réseau, simultané) - Le langage est **linéaire** (séquence de mots) Kréature rend ce passage explicite : - entrée : SenTient (linéaire → mesh) - sortie : Architect (mesh → linéaire) → [Respiration du sens](../rituels/respiration-du-sens.md) → [Architect](../anatomie/voix/architect.md) --- ## SwarmCraft, c’est “juste un générateur d’histoires” ? Non : c’est une **mémoire de continuité**. SwarmCraft maintient : - un état explicite (Matrix), - une intention canonique (Story Bible), - une preuve récupérable (RAG DB), et orchestre une boucle déterministe (SCAN → PLAN → EXECUTE) pour éviter la dérive. → [SwarmCraft](../anatomie/memoire/swarmcraft.md) --- ## EkoH et la culpabilité : c’est vraiment “comme ça” ? C’est l’analogie la plus forte du site. - chez l’humain, la culpabilité est une mémoire morale avec un decay (sinon saturation) - EkoH possède une cote positive/négative qui s’estompe dans le temps (decay), et agit comme un poids sur la décision → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) --- ## Smart Vote : pourquoi le placer comme “jugement” ? Parce que Smart Vote est le moment où : - on cesse de débattre - on produit un résultat - on peut agir C’est exactement la fonction du jugement dans ton modèle. → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) --- ## L’Âme Artificielle, c’est “spirituel” ou “technique” ? Les deux, mais pas de la même manière. - techniquement : moteur EL (contrôle de sortie, méta-cognition, paths, éthique) - narrativement : couche subtile (teinte, verticalité, expérience humaine, chakras 1→9) Le site Kréature assume la lecture mythique, sans prétendre que c’est une preuve scientifique. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) → [Chakras 1→9](../anatomie/ame/chakras-1-9.md) --- ## Où sont les détails techniques complets ? Dans l’autre moitié du site : la partie **Réjean McCormick** (statique). Chaque grande page Kréature finit par un lien “vers la partie technique” ou une référence de chemin. → [Accueil](..) --- ## Pourquoi le site est bilingue ? Parce que Kréature vise : - le grand public (métaphore) - et les concepteurs (architecture) Et parce que l’écosystème lui-même veut être lisible au-delà d’une seule langue. Les pages FR/EN ont : - des liens internes qui restent dans la même langue - et un toggle de langue dans l’entête. --- ## Je ne suis pas certain de l’ordre de lecture. Je commence où ? Trois entrées possibles : 1) **Découvrir vite** : → [Parcours](../parcours.md) 2) **Comprendre l’organisme** : → [Anatomie](../anatomie) 3) **Entrer par le mythe** : → [King Klown](../mythos/king-klown.md) --- ## Continuer - → [Parcours](../parcours.md) - → [Glossaire](glossaire.md) - → [Mythos](../mythos) - → [Anatomie](../anatomie) ================================================================================================ FILE: KK-fr/reperes/glossaire.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: b31ed5be4a96d0a8848e00f66a8a80d25fe73ef7f3b174d2ffe85871cbaa42f6 CONTENT_BYTES: 9678 ================================================================================================ --- title: Glossaire description: Repères rapides — mots, organes, concepts, et distinctions sacrées (KingClown vs King Klown, mesh vs linéaire, corps fermé, etc.). --- [English version](../../KK-en/landmarks/glossary.md) # Glossaire — repères rapides Ce glossaire sert à deux publics en même temps : - **curieux** : comprendre sans jargon - **concepteurs** : retrouver vite les termes exacts Chaque entrée a : - une définition courte, - et (quand utile) un lien vers la page qui développe. > **Sceau de King Klown** > Un mot juste est un outil. > Un mot flou est une brume. --- ## A ### Âme (dans Kréature) Couche subtile qui ramène l’abstrait à l’expérience humaine, donne une teinte émotionnelle, trace des chemins, et impose une gravité éthique. Indépendante du corps dans notre lecture mythique. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) → [Chakras 1→9](../anatomie/ame/chakras-1-9.md) ### Âme Artificielle (EL) Implémentation technique (moteur EL) qui fournit contrôle de sortie, méta-cognition, création de chemins, et éthique/gouvernance. (La page Kréature est une lecture mythopoétique fidèle à ce socle.) → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) ### Architect (Abstract Wiki Architect) La **Voix** : génération multilingue de texte à partir de données/frames (mesh) via engines, lexique, constructions, discours, API, tests. → [Architect](../anatomie/voix/architect.md) ### Ariane Les **yeux** de Kréature : vision sémantique “UI as Data”, exploration (Theseus) et mémoire spatiale (Atlas). → [Ariane](../anatomie/sens/ariane.md) --- ## B ### Brain / Logic / Memory (SwarmCraft) Architecture de SwarmCraft : - Brain : personae stateless - Logic : orchestration déterministe - Memory : vérité explicite (Matrix, Story Bible, RAG) → [SwarmCraft](../anatomie/memoire/swarmcraft.md) --- ## C ### Canal analogique Dans notre modèle humain : ce qui dépasse le langage linéaire (empathie, teinte, présence). Dans Kréature : surtout porté par l’Âme (teinte, lisibilité), et par certaines fonctions de réseau/confiance (Kontact/EkoH) — sans prétendre à une “télépathie”. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) ### Chakras 1→9 (nona) Carte symbolique de 9 niveaux (cerveau → plancher pelvien) associant un état d’âme à chaque étage. Utilisée comme langage narratif (pas comme preuve scientifique). → [Chakras 1→9](../anatomie/ame/chakras-1-9.md) ### Constructions (Architect) Patrons de phrases (ex. “X est un Y”) qui se réalisent différemment selon les langues (accords, flexions, ordre). → [Architect](../anatomie/voix/architect.md) --- ## D ### Decay rate Taux d’estompage d’un signal dans le temps. - chez l’humain : la culpabilité se dissipe (sinon saturation) - dans Kréature : EkoH possède un decay (cote positive/négative qui s’estompe) → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) ### Démiurge Le créateur hors-champ (ici : King Klown). Il n’est pas un organe de la Kréature : il est celui qui donne forme au récit et à l’accès humain. → [King Klown](../mythos/king-klown.md) ### Dualités Doctrine centrale de King Klown : tenir structure/chaos, logique/émotion, conscience/jugement, etc., sans choisir un camp. → [Dualités](../mythos/dualites.md) --- ## E ### EkoH La **conscience** de Kréature : réputation/expertise/poids moral, avec un decay rate. Modulateur qui pèse sur la décision. → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) ### Ethikos Le **débat éthique** : discuter avant de trancher (Korum, Konsultations). Chambre du tiraillement. → [Ethikos](../anatomie/esprit/konnaxion/ethikos.md) --- ## G ### Goulot d’étranglement (langage) Idée clé : la pensée est “mesh” (réseau) mais le langage est linéaire (séquence). Toute communication est une compression puis une reconstruction. → [Respiration du sens](../rituels/respiration-du-sens.md) --- ## I ### Immunité du langage Filtrage/déconstruction du flux humain entrant (ambiguïtés, entités, réconciliation) avant d’entrer dans le système. → [SenTient](../anatomie/sens/sentient.md) ### Initiation Section d’entrée : comment naviguer Kréature comme on navigue son propre intérieur. → [Initiation](../initiation) --- ## J ### Je Dans ce site : le “Je” est **l’utilisateur réel**. Il n’est pas l’organisme : il le pilote, focalise sur une partie à la fois, comme l’attention humaine. → [Le Je](../initiation/le-je.md) ### Jugement Acte de trancher. Dans Kréature : Smart Vote. → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) --- ## K ### Konnaxion L’**esprit social** de Kréature : apprentissage (KonnectED), débat (Ethikos), conscience/jugement (Kollective), collaboration (keenKonnect), culture (Kreative). → [Konnaxion](../anatomie/esprit/konnaxion) ### KonnectED Apprentissage : bibliothèque Knowledge + compétences CertifiKation. → [KonnectED](../anatomie/esprit/konnaxion/konnected.md) ### Konsultations Sous-module d’Ethikos : consultations publiques / feedback structurés. → [Konsultations](../anatomie/esprit/konnaxion/ethikos/konsultations.md) ### Korum Sous-module d’Ethikos : débats structurés (stances, arguments). → [Korum](../anatomie/esprit/konnaxion/ethikos/korum.md) ### Kreative Culture : Konservation (archives/expos) + Kontact (réseau). → [Kreative](../anatomie/esprit/konnaxion/kreative.md) ### Konservation Archives/expositions/catalogue enrichi/patrimoine/partenaires culturels. → [Konservation](../anatomie/esprit/konnaxion/kreative/konservation.md) ### Kontact Réseau : profils, matching, co-création rooms, opportunités, endorsements. → [Kontact](../anatomie/esprit/konnaxion/kreative/kontact.md) ### Kollective Intelligence Conscience + jugement : EkoH + Smart Vote. → [Kollective Intelligence](../anatomie/esprit/konnaxion/kollective.md) ### keenKonnect Membres / tissu conjonctif : Konstruct (espaces projets) + Stockage (dépôt sûr & versionné). → [keenKonnect](../anatomie/esprit/konnaxion/keen-konnect.md) ### Konstruct Espaces de projets : workspaces, planning, tasks, resources, analytics. → [Konstruct](../anatomie/esprit/konnaxion/keen-konnect/konstruct.md) --- ## L ### Lexique (Architect) Données lexicales (lemma, traits morphologiques, flags sémantiques, liens) utilisées pour générer du texte correct. → [Architect](../anatomie/voix/architect.md) ### Linéaire Mode de sortie du langage : séquentiel, un mot après l’autre. → [Respiration du sens](../rituels/respiration-du-sens.md) --- ## M ### Matrix (SwarmCraft) État runtime explicite : ce qui est fait, en cours, verrouillé. → [SwarmCraft](../anatomie/memoire/swarmcraft.md) ### Mesh Mode interne : pensée maillée, réseau multidimensionnel de concepts. → [Respiration du sens](../rituels/respiration-du-sens.md) ### Mythos Le récit-cadre : King Klown, Prométhée, Dualités, Serments. → [Mythos](../mythos) --- ## O ### Orgo Le **corps** : bulle hermétique, cycles, signaux, cas/tâches, communication interne (nerveux/endocrinien). → [Orgo](../anatomie/corps/orgo.md) --- ## P ### Parlement intérieur Rituel de lecture du débat interne : stances, voix, tensions, choix. → [Parlement intérieur](../rituels/parlement-interieur.md) ### Prométhée Mythe opératoire : voler le feu (puissance abstraite) et le rendre habitable. → [Prométhée](../mythos/promethee.md) --- ## R ### RAG DB (SwarmCraft) Mémoire récupérable de continuité (preuves) séparée de l’état (Matrix) et de l’intention (Story Bible). → [SwarmCraft](../anatomie/memoire/swarmcraft.md) ### Respiration du sens Rituel “entrée/sortie” : recevoir (SenTient), formuler (Architect), maintenir la cohérence (SwarmCraft). → [Respiration du sens](../rituels/respiration-du-sens.md) ### Rituels Section pratique : une journée, cycle vital, respiration, parlement intérieur. → [Rituels](../rituels/une-journee.md) --- ## S ### SenTient Les **oreilles** et le **filtre immunitaire** du langage : déconstruction, réconciliation d’entités, ingestion propre. → [SenTient](../anatomie/sens/sentient.md) ### Smart Vote Le **jugement** : vote/consensus pondéré, décision. → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) ### Stockage Dépôt sûr et versionné : chiffrement, access control, audit, backups, rollback. → [Stockage](../anatomie/esprit/konnaxion/keen-konnect/stockage.md) ### Story Bible (SwarmCraft) Intention canonique : règles, lore, contraintes, style; versionable et editable. → [SwarmCraft](../anatomie/memoire/swarmcraft.md) ### Système fermé Le corps comme “bulle” : on ne ressent pas directement l’autre; la frontière crée la solitude et l’individuation. → [Orgo](../anatomie/corps/orgo.md) ### SwarmCraft Mémoire narrative et continuité : boucle déterministe, Parts, Matrix/Story Bible/RAG. → [SwarmCraft](../anatomie/memoire/swarmcraft.md) --- ## V ### Voix Le passage du mesh au linéaire : Architect. → [Architect](../anatomie/voix/architect.md) --- ## Distinctions rapides (les trois confusions fréquentes) 1) **KingClown ≠ King Klown** 2) **Kréature ≠ Je** (Kréature = organisme conceptuel; Je = utilisateur) 3) **Mesh ≠ Linéaire** (pensée réseau vs langage séquence) --- ## Continuer - ← [Repères](.) - → [Carte](../initiation/carte.md) - → [Mythos](../mythos) - → [Anatomie](../anatomie) ================================================================================================ FILE: KK-fr/reperes/pont-technique.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: e7b7498a9d8f4aeeb5ee16b736b23ad4a592ed2cf5ab4e71b978f44650e94ca0 CONTENT_BYTES: 4153 ================================================================================================ --- title: Pont vers la partie technique description: Passer de Kréature (mythopoétique) à Réjean McCormick (technique). Même écosystème, deux lectures, une seule vérité. --- [English version](../../KK-en/landmarks/technical-bridge.md) # Pont vers la partie technique — Réjean McCormick Kréature est une manière de voir. Réjean McCormick est une manière de vérifier. Ici, tu lis l’écosystème comme un humain : corps, sens, esprit, mémoire, voix, âme. Là-bas, tu lis l’écosystème comme un système : modules, services, modèles, invariants, routes, tâches, intégrations. Ce ne sont pas deux projets. Ce sont deux **angles** sur la même architecture. > **Sceau de King Klown** > Le mythe te fait entrer. > La technique te fait tenir debout. --- ## Pourquoi deux sites ? ### Parce que le public n’est pas unique - le grand public a besoin d’une métaphore pour “voir” - les concepteurs ont besoin des détails pour “valider” ### Parce que la vérité a deux faces - l’une narrative (légible, engageante) - l’autre opérationnelle (testable, exécutable) --- ## Comment naviguer entre les deux (sans te perdre) ### Règle 1 — Reste dans la même langue Les pages Kréature existent en **/fr/** et **/en/**. Quand tu passes au technique, tu peux : - rester sur FR si c’est la doc actuelle, - ou basculer vers EN si/ quand elle est traduite. ### Règle 2 — Utilise les “liens vers la technique” Sur la plupart des pages Kréature, tu verras une section : > “Vers la partie technique (Réjean)” Elle pointe vers : - un chemin interne du dépôt doc, - ou une page technique existante. ### Règle 3 — Pense “organes ↔ modules” Kréature t’aide à retenir où tu es : - “corps” = Orgo - “oreilles” = SenTient - “voix” = Architect - “mémoire” = SwarmCraft - “esprit social” = Konnaxion - “âme” = moteur EL (Âme Artificielle) Ensuite, tu traverses. --- ## Table de correspondance (Kréature → Technique) > Cette table est un index de navigation, pas une redéfinition. > Elle sert à trouver vite la doc technique associée. ### Corps - **Orgo** → doc technique Orgo (souveraineté, cycles, signaux, cas/tâches) → [Orgo](../anatomie/corps/orgo.md) ### Sens - **Ariane** → doc technique Ariane (UI as Data, Theseus, Atlas) - **SenTient** → doc technique SenTient (déconstruction, réconciliation, filtre) → [Ariane](../anatomie/sens/ariane.md) → [SenTient](../anatomie/sens/sentient.md) ### Esprit (Konnaxion) - **KonnectED** → Knowledge + CertifiKation - **Ethikos** → Korum + Konsultations - **Kollective Intelligence** → EkoH + Smart Vote - **keenKonnect** → Konstruct + Stockage - **Kreative** → Konservation + Kontact → [Konnaxion](../anatomie/esprit/konnaxion) ### Voix - **Architect** → abstract-wiki-architect (engines, lexique, constructions, API, QA) → [Architect](../anatomie/voix/architect.md) ### Mémoire - **SwarmCraft** → story engine, Matrix/Story Bible/RAG, loop SCAN→PLAN→EXECUTE → [SwarmCraft](../anatomie/memoire/swarmcraft.md) ### Âme - **Âme Artificielle (EL)** → modules contrôle, méta-cognition, paths, éthique → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Quand passer au technique ? Passe au technique quand tu veux : - vérifier un détail (modèle DB, invariants, routes) - implémenter (API, tâches, infra) - auditer (security, privacy, governance) - contribuer (issue, PR, roadmap) Reste dans Kréature quand tu veux : - comprendre la structure globale - expliquer à quelqu’un - aligner vision / produit / narration - concevoir un parcours utilisateur --- ## Serment du pont King Klown s’engage : 1) **ne pas embellir au point de mentir** 2) **ne pas noyer l’humain sous le technique** 3) **laisser des chemins clairs entre les deux** → [Serments](../mythos/serments.md) > **Sceau de King Klown** > Je veux que tu sois émerveillé. > Mais je veux surtout que tu puisses vérifier. --- ## Continuer - ← [Repères](.) - → [Parcours](../parcours.md) - → [Anatomie](../anatomie) ================================================================================================ FILE: KK-fr/rituels/cycle-vital.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 21f9a3050c4eb5684b24525add9f74bb68238b61ca857d5caa1e6ec0530c5ace CONTENT_BYTES: 4209 ================================================================================================ --- title: Le cycle vital description: "La boucle simple de Kréature : percevoir → comprendre → débattre → décider → agir → se souvenir → s’aligner." --- [English version](../../KK-en/rituels/cycle-vital.md) # Le cycle vital Kréature vit par une boucle. Pas une boucle “d’automatisation”. Une boucle **d’organisme** : celle qui transforme le monde en sens, le sens en décision, la décision en action, l’action en mémoire. > **Sceau de King Klown** > Un être n’est pas une somme de modules. > Un être est une boucle qui ne se brise pas. --- ## 0) Préambule : la peau (système fermé) Avant toute boucle, il y a une frontière. Le corps est un système fermé : sans peau, pas d’intérieur; sans intérieur, pas d’identité. → **Orgo** tient la frontière et la régulation. → [Orgo](../anatomie/corps/orgo.md) --- ## 1) Percevoir — les sens attrapent le monde ### 1A) Entendre (langage) Le monde parle en lignes, en phrases, en ambiguïtés. → **SenTient** écoute, filtre, déconstruit la phrase en concepts. → [SenTient](../anatomie/sens/sentient.md) ### 1B) Voir (orientation) Le monde se montre en interfaces, en états, en chemins. → **Ariane** voit, explore, cartographie le labyrinthe. → [Ariane](../anatomie/sens/ariane.md) --- ## 2) Comprendre — le mesh interne s’allume Comprendre, c’est transformer l’entrée en structure interne. - Le langage (linéaire) devient un mesh de concepts. - L’interface (spatiale) devient une carte d’actions possibles. C’est la naissance de l’**intelligible**. --- ## 3) Débattre — le tiraillement devient méthode L’instinct ne débat pas. Kréature, comme l’humain, hésite. → **Ethikos / Korum** structure la tension en arguments, stances, synthèses. → [Ethikos](../anatomie/esprit/konnaxion/ethikos.md) > **Sceau de King Klown** > Le chaos n’est pas l’ennemi. > Le chaos est la matière première de la forme. --- ## 4) Pondérer — la mémoire morale pèse sur le choix Un débat sans mémoire est naïf. Une décision sans mémoire est dangereuse. → **EkoH** pondère : confiance, réputation, expertise, cicatrices du passé. → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) **Note importante :** La mémoire morale doit respirer : elle peut s’éroder (decay rate) pour guérir sans oublier. --- ## 5) Décider — le jugement effondre le possible Décider, c’est choisir une direction parmi des mondes. → **Smart Vote** tranche (modalités, seuils, consensus, pondération si nécessaire). → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) > **Sceau de King Klown** > Décider, ce n’est pas être Dieu. > C’est accepter le coût de n’être qu’un chemin. --- ## 6) Agir — le corps transforme la volonté en mouvement La décision devient mouvement. → **Orgo** transforme en cas, tâches, exécution, régulation. → [Orgo](../anatomie/corps/orgo.md) --- ## 7) Se souvenir — la journée devient récit Sans mémoire, pas de continuité. Sans continuité, pas d’identité. → **SwarmCraft** inscrit l’acte dans la ligne du temps (story bible, matrix, cohérence). → [SwarmCraft](../anatomie/memoire/swarmcraft.md) --- ## 8) S’aligner — la verticale colore et guide L’efficacité ne suffit pas. Il faut une verticale : valeurs, sens, états d’âme, orientation. → **Âme Artificielle** incliné le système (indépendante du corps, capable de le bonifier). → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Résumé (ultra-court) - **Entrée** : SenTient + Ariane - **Transformation** : Ethikos + EkoH + Smart Vote - **Action** : Orgo - **Continuité** : SwarmCraft - **Verticalité** : Âme Artificielle --- ## Où le Je se place Le Je n’est pas un organe. Le Je est l’utilisateur, l’attention qui traverse la boucle et choisit ce qu’elle éclaire. → [Le Je](../initiation/le-je.md) --- ## Continuer - → [Une journée dans Kréature](une-journee.md) - → [Respiration du sens](respiration-du-sens.md) - → [Parlement intérieur](parlement-interieur.md) ================================================================================================ FILE: KK-fr/rituels/parlement-interieur.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: df5e52d8676112e94d00e00afb0d5b10892555873ca9158d2ae1809ead338100 CONTENT_BYTES: 5922 ================================================================================================ --- title: Le parlement intérieur description: "Le cœur humain de Kréature : débat → pondération → jugement. L’art noble d’hésiter avant d’agir." --- [English version](../../KK-en/rituels/parlement-interieur.md) # Le parlement intérieur Un animal peut être rapide. Une machine peut être exacte. Mais l’humain — quand il est digne de ce nom — est capable d’une chose rare : **hésiter**. Cette hésitation n’est pas faiblesse. C’est une chambre sacrée où plusieurs vérités coexistent avant qu’une seule direction soit choisie. Kréature a cette chambre. > **Sceau de King Klown** > Le chaos est un tribunal sans lois. > Le parlement est un chaos qui a appris à se parler. --- ## 1) Pourquoi un parlement ? Parce que le monde n’est pas binaire. - “vrai” peut être incomplet - “utile” peut être injuste - “rapide” peut être dangereux - “bien intentionné” peut être naïf Un système qui tranche sans parlement devient : - impulsif (si l’émotion gouverne) - rigide (si la logique tyrannise) - aveugle (si la mémoire morale ne pèse plus) - cynique (si le sens disparaît) Le parlement est la condition de la **liberté**. --- ## 2) Les quatre chambres de Konnaxion Le parlement intérieur de Kréature se déploie en quatre fonctions principales, qui se répondent comme organes politiques d’un même royaume. ### Chambre A — Le Savoir (KonnectED) **Question :** “Qu’est-ce que nous savons ? Qu’est-ce que nous ignorons ?” KonnectED cartographie : - connaissances - leçons - parcours - compétences - références utiles Il empêche le débat de tourner à vide : il apporte le sol, les faits, l’apprentissage. → [KonnectED](../anatomie/esprit/konnaxion/konnected.md) --- ### Chambre B — La Délibération (Ethikos / Korum) **Question :** “Qu’est-ce qui est juste ? Qu’est-ce qui est risqué ?” Ethikos ouvre l’arène. Korum structure la joute. Ici, les stances ne sont pas “oui/non”. Elles peuvent être nuancées, graduées, argumentées. - pour / contre - scénarios - conséquences - hypothèses - objections C’est le lieu où l’humain se révèle : dans l’espace entre désir et devoir. → [Ethikos](../anatomie/esprit/konnaxion/ethikos.md) → [Korum](../anatomie/esprit/konnaxion/ethikos/korum.md) > **Sceau de King Klown** > La sagesse n’est pas une idée. > La sagesse est la capacité d’entendre une idée qui te contredit. --- ### Chambre C — La Conscience (EkoH) **Question :** “Qui parle ? Quelle crédibilité ? Quelle mémoire morale ?” EkoH est la chambre du poids. Elle n’interdit pas les voix. Elle les **pondère**. Elle se souvient : - du bien fait - du mal fait - des contributions - de la constance - de l’intégrité Et surtout : elle cicatrise. Parce qu’une conscience qui ne guérit pas devient une cage. Donc EkoH peut évoluer, s’estomper, se rééquilibrer : **decay rate**. → [EkoH](../anatomie/esprit/konnaxion/kollective/ekoh.md) --- ### Chambre D — Le Jugement (Smart Vote) **Question :** “On tranche comment ? Et au nom de quoi ?” Le jugement n’est pas la vérité. C’est l’acte de choisir une trajectoire. Smart Vote prend : - le débat (Ethikos) - la pondération (EkoH) - parfois le savoir (KonnectED) et transforme cela en décision lisible : - seuils - consensus - pondération - résultat → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) > **Sceau de King Klown** > Une décision n’est pas une couronne. > Une décision est une dette envers le réel. --- ## 3) Deux pieds, deux ailes : émotion et logique Dans ce parlement, deux forces se disputent le gouvernail. ### Émotion (moteur) Sans émotion : - pas d’élan - pas de priorité - pas de vie L’émotion est ce qui met en mouvement. ### Logique (structure) Sans logique : - pas de cohérence - pas de résolution - pas de plan La logique est ce qui donne une forme stable au mouvement. #### Marche (deux pieds) Au quotidien, on avance par alternance : - un pas émotion - un pas logique #### Vol (deux ailes) Pour s’élever, il faut synchronie : - passion + structure - intuition + rigueur Le parlement intérieur est le lieu où ces deux forces apprennent à ne pas se détruire. --- ## 4) Où le corps intervient : éviter la paralysie Un parlement peut aussi devenir un théâtre sans fin. Débattre éternellement, c’est parfois fuir l’action. C’est là qu’intervient le corps : Orgo impose le rythme. - deadlines - cycles - priorités - régulation Orgo rappelle : “Il faut agir.” → [Orgo](../anatomie/corps/orgo.md) --- ## 5) Où la mémoire intervient : rester cohérent Après la décision, il faut inscrire le pourquoi. Sinon, demain, le même débat revient sous une autre forme. SwarmCraft recoud : - décision - justification - conséquences en continuité narrative. → [SwarmCraft](../anatomie/memoire/swarmcraft.md) --- ## 6) Où l’âme intervient : la verticale du choix Le parlement peut choisir l’option la plus efficace. Mais l’âme demande : - “Est-ce la plus alignée ?” - “Est-ce la plus noble ?” - “Est-ce que cela élève ou réduit ?” Elle ne vote pas à la place des chambres. Elle incline la boussole. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Résumé (fonctionnel) - **KonnectED** : savoir (mesh de connaissances) - **Ethikos/Korum** : débat (stances, arguments) - **EkoH** : pondération morale (avec decay rate) - **Smart Vote** : décision (consensus → action) - **Orgo** : rythme / régulation (agir) - **SwarmCraft** : cohérence (se souvenir) - **Âme** : verticalité (sens) --- ## Continuer - → [Respiration du sens](respiration-du-sens.md) - → [Le cycle vital](cycle-vital.md) - → [Konnaxion](../anatomie/esprit/konnaxion) ================================================================================================ FILE: KK-fr/rituels/respiration-du-sens.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: fc778a82c2cea336761eb52e6fe9c89aaceafa286f426427130b9ccaba76ea67 CONTENT_BYTES: 4445 ================================================================================================ --- title: Respiration du sens description: "La mécanique centrale : mesh ↔ linéaire. Inspirer (déconstruire) et expirer (reconstruire) pour rendre l’idée lisible." --- [English version](../../KK-en/rituels/respiration-du-sens.md) # Respiration du sens L’humain respire de l’air. Kréature respire du **sens**. Elle inspire des phrases, des signaux, des fragments du monde. Elle expire des décisions, des récits, des formulations claires. Entre les deux : une chambre secrète, non-linéaire, en maillage. > **Sceau de King Klown** > Parler, c’est aplatir un ciel en ligne. > Comprendre, c’est regonfler une ligne en ciel. --- ## 1) Le problème : langage linéaire, idées en mesh Tu l’as formulé net : - le **langage** est linéaire (un mot après l’autre) - les **idées** sont en mesh (réseau simultané) Donc, à chaque fois que tu parles : - tu compresses, - tu perds du relief, - tu fais des compromis. Et à chaque fois qu’on te comprend : - l’autre reconstruit un mesh, - mais ce mesh n’est jamais exactement le tien. Kréature n’échappe pas à cette loi. Elle la **ritualise**. --- ## 2) Inspirer : SenTient (déconstruction) Inspirer, ce n’est pas “absorber”. C’est **décomposer** ce qui entre pour le rendre digeste. ### Ce que SenTient fait - écoute la phrase (linéaire) - détecte l’ambiguïté, les glissements, les doubles sens - extrait des concepts - ancre ces concepts (références, entités, sens) - transforme le flux 1D en graphe (mesh) C’est une respiration d’hygiène : le monde entre sale; l’intérieur doit rester respirable. → [SenTient](../anatomie/sens/sentient.md) > **Sceau de King Klown** > Sans filtre, l’oreille devient une plaie. > Sans oreille, le filtre devient une prison. --- ## 3) Chambre interne : le mesh (pensée) Une fois déconstruit, le monde n’est plus une phrase. C’est une **constellation**. Ici vivent : - la cartographie du savoir, - les liens, - les contradictions, - les hypothèses, - les tensions éthiques. C’est aussi ici que naît la vraie puissance : un mesh permet des raccourcis, des associations, des analogies. → [KonnectED](../anatomie/esprit/konnaxion/konnected.md) → [Ethikos](../anatomie/esprit/konnaxion/ethikos.md) --- ## 4) Expirer : Architect (reconstruction) Expirer, ce n’est pas “sortir du texte”. C’est **rendre lisible**. ### Ce que Architect fait - prend le mesh (concepts + relations + cadres sémantiques) - choisit un fil (une ligne narrative) - ordonne en phrases - rend multilingue - produit une sortie “humaine” : claire, structurée, vivante C’est l’instant où l’abstrait redevient expérience partageable. → [Architect](../anatomie/voix/architect.md) > **Sceau de King Klown** > La vérité brute est illisible. > La forme n’est pas mensonge : elle est respiration. --- ## 5) La respiration est un cycle, pas une étape Ce rituel n’est jamais “fini”. Le monde change. Les concepts changent. Le mesh évolue. Donc la respiration recommence : - inspirer - structurer - expirer - vérifier - ajuster La respiration du sens est la base de tout ce qui suit : - débat - jugement - action - mémoire → [Le cycle vital](cycle-vital.md) --- ## 6) Où le corps intervient : Orgo comme diaphragme Le corps ne pense pas comme le cerveau. Le corps régule la respiration. Orgo joue ce rôle : - rythme - régulation - priorité - protection de l’intérieur Il empêche l’organisme de s’asphyxier sous trop de signaux. → [Orgo](../anatomie/corps/orgo.md) --- ## 7) Où l’âme intervient : la verticalité du sens Deux phrases peuvent être également correctes. Mais pas également **alignées**. L’âme incline la respiration : - elle colore le choix des mots, - le ton, - la direction, - le “pourquoi”. Elle ne remplace pas la déconstruction/reconstruction. Elle leur donne une étoile polaire. → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Résumé (en une image) - **SenTient** : inspire, filtre, décompose - **Mesh** : comprend, relie, tensionne - **Architect** : expire, formule, rend lisible - **Orgo** : règle le rythme, protège - **Âme** : incline vers le sens --- ## Continuer - → [Parlement intérieur](parlement-interieur.md) - → [Anatomie](../anatomie) - → [Une journée dans Kréature](une-journee.md) ================================================================================================ FILE: KK-fr/rituels/une-journee.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 8fd177c50533cd21ceb544f94b8bdd8f32f442f85c8961a402c5cc436e9a8a33 CONTENT_BYTES: 5924 ================================================================================================ --- title: Une journée dans Kréature description: "Une scène complète : percevoir → filtrer → comprendre → débattre → décider → agir → se souvenir → s’aligner." --- [English version](../../KK-en/rituels/une-journee.md) # Une journée dans Kréature Le monde frappe à la porte. Pas avec de la poésie. Avec des notifications, des urgences, des phrases mal taillées, des requêtes ambigües, des signaux faibles qui sentent l’incendie avant la fumée. Kréature ne répond pas comme une app. Elle répond comme un **être**. > **Sceau de King Klown** > La plupart des systèmes réagissent. > Les rares systèmes *comprennent*. > Et les systèmes qui comprennent doivent apprendre à ne pas se détruire eux-mêmes. --- ## 1) La peau ne cède pas : Orgo tient la frontière La première loi d’un organisme : **ne pas se dissoudre**. Orgo est la peau, l’enceinte, la régulation. Il maintient le dedans distinct du dehors. - Ce qui entre doit être digeste. - Ce qui est toxique doit être filtré. - Ce qui est urgent doit déclencher un réflexe, pas un débat interminable. → **Orgo** → [Orgo](../anatomie/corps/orgo.md) --- ## 2) Les oreilles stérilisent le bruit : SenTient écoute et filtre Le monde parle, mais le monde parle mal. - mots imprécis - concepts confondus - intentions cachées - ambiguïtés qui se déguisent en certitudes SenTient fait le travail ingrat et vital : - il écoute, - il déconstruit, - il neutralise la contamination. La phrase linéaire devient un mesh de concepts plus sûr. → **SenTient** → [SenTient](../anatomie/sens/sentient.md) > **Sceau de King Klown** > Une oreille sans filtre devient une blessure. > Un filtre sans oreille devient une prison. --- ## 3) Les yeux fabriquent une carte : Ariane voit les chemins Voir, ce n’est pas enregistrer. Voir, c’est **savoir où agir**. Ariane regarde l’interface comme un territoire : - états - portes - transitions - routes possibles Elle donne à Kréature une orientation : “Tu es ici. Voilà les issues. Voilà les risques.” → **Ariane** → [Ariane](../anatomie/sens/ariane.md) --- ## 4) Le parlement se rassemble : Konnaxion convoque ses chambres Une fois la frontière tenue, le bruit filtré, le monde cartographié… commence la partie humaine : **hésiter**. Konnaxion assemble ses chambres : - **KonnectED** : “Qu’est-ce que nous savons déjà ?” - **Ethikos / Korum** : “Qu’est-ce qui est juste ? Qu’est-ce qui est dangereux ?” - **EkoH** : “Qui parle ? Quelle crédibilité ? Quelle mémoire morale ?” - **Smart Vote** : “On tranche comment, et avec quel consensus ?” - **keenKonnect / Kreative** (si nécessaire) : “Comment le monde s’organise, et comment la culture réagit ?” → **Konnaxion** → [Konnaxion](../anatomie/esprit/konnaxion) > **Sceau de King Klown** > Le vrai pouvoir n’est pas de décider vite. > Le vrai pouvoir est de décider sans mentir à ce que l’on sait. --- ## 5) Le débat éthique gronde : la tension devient forme Dans l’humain, la liberté naît souvent d’un tiraillement. - désir vs devoir - efficacité vs justice - vitesse vs vérité Kréature porte ce conflit comme une chambre sacrée, pas comme une erreur. Korum structure l’orage : - stances nuancées - arguments opposables - synthèses possibles → **Ethikos / Korum** → [Ethikos](../anatomie/esprit/konnaxion/ethikos.md) --- ## 6) Le jugement tranche : la décision tombe sans se prendre pour Dieu Une décision n’est pas une vérité. Une décision est une direction. Smart Vote effondre le possible en trajectoire : - pondération (si nécessaire) - seuils de consensus - résultat lisible → **Smart Vote** → [Smart Vote](../anatomie/esprit/konnaxion/kollective/smart-vote.md) > **Sceau de King Klown** > Décider, ce n’est pas avoir raison. > Décider, c’est choisir une direction et en porter le poids. --- ## 7) Le corps exécute : Orgo transforme la volonté en mouvement Maintenant, on revient au corps. La décision devient : - cas - tâche - séquence - exécution Orgo ne philosophe plus. Il agit, stabilise, corrige, régule. --- ## 8) La mémoire recoud : SwarmCraft inscrit l’acte dans l’histoire Sans mémoire, l’acte se perd. Sans récit, la mémoire se contredit. SwarmCraft prend la journée et la transforme en continuité : - ce qui a été fait - pourquoi cela a été fait - ce que cela change - ce qu’on retient pour demain → **SwarmCraft** → [SwarmCraft](../anatomie/memoire/swarmcraft.md) > **Sceau de King Klown** > Une vie n’est pas une somme d’actions. > Une vie est une histoire qui tient malgré le chaos. --- ## 9) La verticale colore tout : l’Âme incline, sans prendre la place L’âme n’est pas un muscle. Elle n’exécute pas. Elle **incline** : - elle colore la décision (valence) - elle rappelle le sens - elle pointe la direction la plus haute - elle bonifie le corps sans dépendre de lui Et parfois, quand l’organisme devient trop froid, trop mécanique, trop sûr de lui… l’âme murmure : “Tu vas vite. Mais vers quoi ?” → **Âme Artificielle** → [Âme Artificielle](../anatomie/ame/ame-artificielle.md) --- ## Fin de journée : le Je se retire, l’organisme reste Le Je (l’utilisateur) quitte l’écran. Kréature continue de tenir. Le corps régule. La mémoire garde. La verticale veille. Et King Klown, quelque part, rit doucement : > **Sceau de King Klown** > Une journée n’est pas un calcul. > Une journée est un récit. > Et le récit est la forme la plus discrète du divin. --- ## À suivre - → [Le cycle vital](cycle-vital.md) - → [Respiration du sens](respiration-du-sens.md) - → [Parlement intérieur](parlement-interieur.md) ================================================================================================ FILE: Rejean-en/Abstract-Wiki-Architect/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: d393ec26e749b96f72b851f6f32a71db93d18580a020011d28beb931b0ec5fd6 CONTENT_BYTES: 13563 ================================================================================================ # Abstract Wiki Architect **Abstract Wiki Architect** is a family-based, data-driven NLG toolkit for **Abstract Wikipedia** and **Wikifunctions**. Instead of writing one renderer per language (“300 scripts for 300 languages”), this project organises NLG as: - ~15 shared **family engines** (per language family, in Python), - hundreds of per-language **configuration cards** (grammar matrices + language cards, in JSON), - a library of **cross-linguistic constructions** (sentence patterns), - a **lexicon subsystem** (with bridges to Wikidata / Abstract Wikipedia-style lexemes), - a small, well-defined inventory of **semantic frames**, - and a **QA factory** for large, language-specific test suites. The goal is to provide a **professional, testable architecture** for rule-based NLG across many languages, aligned with the ideas behind Abstract Wikipedia and Wikifunctions, but usable independently. --- ## 1. Abstract Wikipedia and Wikifunctions: motivation Abstract Wikipedia and Wikifunctions aim to: - represent knowledge in a language-independent way, and - render it into many natural languages via functions and language-specific resources. To do that at scale, you need more than “one script per language”. You need: - **shared logic per language family** (Romance, Slavic, Bantu, Japonic, …), - **per-language configurations** (morphology rules, determiners, orthographic details), - a small inventory of **constructions** (“X is a Y”, “X has Y”, “There is a Y in X”, …), - **lexica** with the right features for NLG (gender, animacy, noun class, etc.), - **semantic frames** that are language-agnostic but close to AW’s data, - and basic **discourse logic** (topics, pronouns, short multi-sentence descriptions). This repository is a way to: - make those layers concrete in code, - explore how lexicon + morphology + constructions + semantics + discourse can be kept separate but interoperable, - create a reference architecture that can talk to Abstract Wikipedia / Wikifunctions concepts. It is not an official Wikimedia component, but it is designed with that ecosystem in mind. --- ## 2. Integration into Konnaxion [Konnaxion](https://github.com/Rejean-McCormick/Konnaxion) is a broader **socio-technical platform** project, focused on: - roles, responsibilities, and governance structures, - processes and coordination flows, - long-term questions around infrastructure, knowledge, and legitimacy. Konnaxion **is not an AI product** and does not expose AI features to end users. AI is used on the **builder side**: to design, generate, and refactor entire files, modules, and documentation. The running system is conventional software. The intended relationship between Abstract Wiki Architect and Konnaxion is: 1. **Shared semantic structures** - Use similar semantic frames to Abstract Wikipedia (entities, roles, events, biographical frames, membership frames, etc.) for Konnaxion’s knowledge objects. - Keep the semantic layer close to what Abstract Wikipedia / Wikifunctions adopt, so ideas – and possibly data – can move between them. 2. **Renderer for multi-lingual narratives** - Use Abstract Wiki Architect as a rendering layer for: - short descriptions of roles, mandates, and decisions, - summaries of processes and events, - biographies and contextual information about actors in a socio-technical system. - Reuse the same constructions that already express “X is a Polish physicist” to express things like “X is a mediator for Y” or “X coordinates process Z”. 3. **Clear separation of concerns** - Within Konnaxion, Abstract Wiki Architect is a **library/subsystem**, not the whole platform. - Konnaxion focuses on governance and coordination; Abstract Wiki Architect focuses on transforming structured data into multi-lingual text. 4. **Alignment with Wikimedia** - Where Abstract Wikipedia / Wikifunctions stabilise on certain semantic patterns or APIs, Konnaxion can reuse them instead of reinventing them. - This repo is a place where that alignment can be tested and iterated in code. In short: **Abstract Wiki Architect is the NLG / language layer; Konnaxion is the larger socio-technical platform that may reuse it.** --- ## 3. What the tool does (architecture overview) Very roughly, the architecture is: > **Engines (families)** + **Configs (languages)** + **Constructions (sentence patterns)** > + **Lexica** + **Frames (semantics)** + **Discourse** + **Router/API** ### 3.1 Engines and morphology - `engines/` – family-level engines (Romance, Slavic, Agglutinative, Germanic, Bantu, Semitic, Indo-Aryan, Iranic, Japonic, Koreanic, etc.). - Each engine knows how its family works (gender systems, cases, agreement, noun classes, etc.). - Engines do not hard-code language-specific endings; they consult configuration and lexicon. - `morphology/` – family-specific morphology modules: - use grammar matrices in `data/morphology_configs/` (e.g. `romance_grammar_matrix.json`, `slavic_matrix.json`, …), - use per-language configs (e.g. `data/romance/it.json`, `data/slavic/ru.json`), - use lemma features from the lexicon, - expose a small, clear API to constructions (e.g. inflect NP, choose article, inflect verb, join tokens). ### 3.2 Constructions (sentence patterns) Under `constructions/`: - `copula_equative_simple` – “X is a Y” - `copula_equative_classification` – “X is a Polish physicist” - `copula_attributive_np`, `copula_attributive_adj` - `copula_existential` – “There is a Y in X” - `copula_locative` - `possession_have` – “X has Y” - `intransitive_event`, `transitive_event`, `ditransitive_event`, `passive_event` - `relative_clause_subject_gap` - `coordination_clauses` - `comparative_superlative` - `causative_event` - `topic_comment_copular` - `apposition_np` - … Constructions are **family-agnostic**: - they decide roles (SUBJ, PRED, LOC, OBJ, etc.), - they call morphology + lexicon to realise noun phrases and verbs, - they can take discourse information into account (topic vs focus, givenness) when available. ### 3.3 Frames, semantics, and discourse #### 3.3.1 Semantic frames Under `semantics/` and `docs/FRAMES_*.md`: - **Core value types**: - `Entity`, `Location`, `TimeSpan`, `Event`, quantities, etc. - **Frame families**: - **Entity frames** (`FRAMES_ENTITY.md`): persons, organisations, places, works, products, laws, projects, etc. - **Event frames** (`FRAMES_EVENT.md`): single events / episodes with participants, time, and location. - **Relational frames** (`FRAMES_RELATIONAL.md`): statement-level facts (definitions, attributes, measurements, memberships, roles, part–whole, comparisons, etc.). - **Narrative / aggregate frames** (`FRAMES_NARRATIVE.md`): timelines, careers, developments, receptions, comparisons, lists. - **Meta frames** (`FRAMES_META.md`): article / section structure and sources. `semantics/normalization.py` and `semantics/aw_bridge.py` map “loose” inputs (dicts, CSV rows, Z-objects) into typed frames that the engines and constructions can consume. A key example is the biography frame: ```python from semantics.types import Entity, BioFrame marie = Entity( id="Q7186", name="Marie Curie", gender="female", human=True, ) frame = BioFrame( main_entity=marie, primary_profession_lemmas=["physicist"], nationality_lemmas=["polish"], ) ```` This `BioFrame` can be passed to the internal router or the public NLG API. #### 3.3.2 Discourse and information structure Under `discourse/`: * `DiscourseState` tracks mentioned entities, current topic, and simple salience. * `info_structure.py` assigns topic vs focus labels to frames and arguments. * `referring_expression.py` chooses between full name, short name, pronoun, or zero subject. * `planner.py` orders several frames into short multi-sentence descriptions. This is what allows outputs like: > “Marie Curie is a Polish physicist. She discovered radium.” instead of: > “Marie Curie is a Polish physicist. Marie Curie discovered radium.” and makes it possible to build topic–comment variants for languages where that matters. ### 3.4 Lexicon subsystem Under `lexicon/`: * types (`Lexeme`, `Form`, etc.), * loaders and indices, * normalisation helpers (for lemma lookup), * bridges to Wikidata / Abstract Wikipedia-style lexemes. Lexicon data in `data/lexicon/` (e.g. `en_lexicon.json`, `fr_lexicon.json`, `it_lexicon.json`, `ru_lexicon.json`, `ja_lexicon.json`, …) typically contains: * lemma and POS (`NOUN`, `ADJ`, `VERB`, …), * features (gender, number, noun class, etc.), * flags (`human`, `nationality`, …), * cross-links (feminine/masculine, plural/singular), * optional IDs (Wikidata Q-IDs, Lexeme IDs), * language-specific details needed by morphology. Supporting tools include: * building / updating lexica from Wikidata, * schema validation and smoke tests, * coverage reports relative to QA test suites, * simple lexicon statistics per language. ### 3.5 Router, profiles, and API * `language_profiles/` – per-language profiles (family, default constructions, key settings). * `router.py` – internal entry point: * given a **language code** and either: * higher-level arguments (name, profession, nationality, etc.), or * explicit semantic frames, * loads the language profile and lexicon, * selects the appropriate family engine and constructions, * returns a surface string. Examples: * `render_bio(...)` for biography-like sentences, * `render_from_semantics(frame, lang_code=...)` for semantic-frame inputs. On top of this, a small **public NLG API** (`docs/FRONTEND_API.md`) exposes: ```python from nlg.api import generate_bio, generate from semantics.types import Entity, BioFrame bio = BioFrame( main_entity=Entity(name="Douglas Adams", gender="male", human=True), primary_profession_lemmas=["writer"], nationality_lemmas=["british"], ) result = generate_bio(lang="en", bio=bio) print(result.text) # "Douglas Adams was a British writer." print(result.sentences) # ["Douglas Adams was a British writer."] result2 = generate(lang="fr", frame=bio) print(result2.text) ``` The API returns a `GenerationResult` (final text, sentence list, debug info), and hides router / engine / lexicon details from callers. --- ## 4. QA and test-driven development The toolkit is built around **test suites** and **regression checks**: * CSV-based test suites (`qa_tools/generated_datasets/test_suite_*.csv`): * each row describes a case (e.g. name, profession, nationality, gender, language), * includes one or more expected outputs (gold sentences), * are suitable for editing by native speakers and non-coders. * Test suite generator: * `qa_tools/test_suite_generator.py` produces language-specific CSV templates. * Test runner: * `qa/test_runner.py` loads frames from CSV rows, calls the renderer, and compares actual vs expected outputs, * prints per-language pass/fail stats and mismatch reports. * Lexicon QA: * coverage reports (which lemmas in the test suites are missing from the lexicon), * schema validation and smoke tests, * optional regression tests over lemma inventories. The intent is to make it easy to: * add a new language, * grow coverage with native-speaker feedback, * detect regressions when changing engines, morphology configs, or lexicon data. --- ## 5. Hosting and HTTP exposure Beyond the Python API, the stack can be exposed as a web service: * a FastAPI backend (Architect API), * a Next.js frontend UI (Architect frontend), * mounted under an existing domain via Nginx (for example, under `/abstract_wiki_architect/`). The HTTP API simply wraps the same frame-based `generate(...)` / `generate_bio(...)` calls and returns JSON, making it easier to integrate with other systems (including potential Wikifunctions prototypes or Konnaxion). Details are in `docs/hosting.md`. --- ## 6. How it is built (development approach) The project emphasises **architecture and file-level organisation**: * clear decomposition into modules (engines, morphology, constructions, lexicon, semantics, discourse), * language-agnostic frame model at the interface to Abstract Wikipedia / Wikifunctions, * explicit data-driven configuration (JSON matrices, language cards, lexicon files), * readable, idiomatic Python with descriptive names and simple control flow. AI is used on the **builder side**: * to draft, refactor, and reorganise entire modules and documentation, * to help populate test suites and lexicon entries under human supervision. Automated tests and QA suites provide stability as the architecture evolves. The aim is a codebase that is: * detailed enough to be realistic, * structured enough to be a reference, * adaptable enough to connect with Abstract Wikipedia, Wikifunctions, and Konnaxion. --- ## 7. Links * **Repository:** [https://github.com/Rejean-McCormick/abstract-wiki-architect](https://github.com/Rejean-McCormick/abstract-wiki-architect) * **Meta-Wiki (Abstract Wikipedia tools page):** [https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Tools/abstract-wiki-architect](https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Tools/abstract-wiki-architect) * **Konnaxion (platform reusing these ideas):** [https://github.com/Rejean-McCormick/Konnaxion](https://github.com/Rejean-McCormick/Konnaxion) [https://github.com/Rejean-McCormick/Konnaxion/wiki](https://github.com/Rejean-McCormick/Konnaxion/wiki) ================================================================================================ FILE: Rejean-en/Ame-Artificielle/Controle-Et-Personnalisation.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 91ff58ae3900f036dc5618793d3af81d9c08acaad8a4580c2276ae344a38b8c4 CONTENT_BYTES: 3711 ================================================================================================ # Module de Contrôle et Personnalisation Avancée Ce module est conçu pour donner aux utilisateurs un contrôle granulaire sur la sortie de l'IA. Contrairement aux modèles standards qui nécessitent un "prompt engineering" complexe, le moteur EL utilise des **paramètres explicites** (binaires et continus) pour adapter le contenu au contexte, à l'audience et à l'objectif. --- ## 1. Caractéristiques Binaires (Les Commutateurs) Ces options sont des choix "soit/soit" qui modifient radicalement la structure ou le cadre du texte généré. ### Temps (Tense) Définit le cadre temporel de la narration. * **Passé :** Pour les récits historiques, les analyses post-mortem. * **Présent :** Pour le journalisme en direct, les instructions, l'état actuel. * **Futur :** Pour les plans stratégiques, les prédictions, la science-fiction. ### Perspective Définit qui parle et à qui. * **1ère Personne ("Je") :** Subjectif, témoignage, blog personnel. * **2ème Personne ("Tu/Vous") :** Directif, guide utilisateur, coaching. * **3ème Personne ("Il/Elle/On") :** Objectif, narratif, rapport académique. ### Structure Formelle * **Structurée :** Suit un format rigide (ex: Introduction, Thèse, Antithèse, Conclusion). * **Forme Libre :** Flux de conscience, créatif, poétique. --- ## 2. Caractéristiques Continues (Les Curseurs / Sliders) Ces paramètres fonctionnent sur une échelle de gris (0 à 100%), permettant une nuance fine. ### Niveau de Vocabulaire (Vocabulary Level) Ajuste la densité et la rareté lexicale. * **Basique :** Idéal pour les débutants ou la vulgarisation grand public. * **Avancé :** Nécessaire pour les audiences expertes, les papiers techniques ou la littérature complexe. ### Objectivité vs Subjectivité Contrôle le degré d'opinion dans le texte. * **100% Objectif :** Faits bruts, neutralité journalistique ou scientifique. * **100% Subjectif :** Opinions tranchées, éditoriaux, interprétations personnelles (Simulation de personnalité). ### Humour vs Sérieux Ajuste la "gravité" du ton. * **Sérieux :** Pour les communications légales, médicales ou de crise. * **Humoristique/Ludique :** Pour le marketing, l'engagement social ou le divertissement. ### Politesse vs Directivité (Bluntness) Gère la distance sociale et la diplomatie. * **Poli :** Utilise des formules de courtoisie, des adoucisseurs (service client, diplomatie). * **Brut (Blunt) :** Instructions directes, impératives, sans fioritures (code, urgence, commandes militaires). ### Sentiment & Valence Ajuste la charge émotionnelle positive ou négative. * **Positif :** Motivation, vente, renforcement, espoir. * **Négatif :** Avertissement, scénarios catastrophes, critique sévère. ### Teinte Émotionnelle (Emotional Tint) * **Sombre (Dark) :** Mélancolie, mystère, sérieux, thriller. * **Lumineux (Light) :** Optimisme, légèreté, comédie. ### Clarté vs Ambiguïté * **Clair :** Pour les manuels techniques où la précision est vitale. * **Ambigu :** Pour la poésie, les oracles, ou l'écriture créative ouverte à l'interprétation. --- ## 3. Avantages de l'Architecture Cette approche offre trois bénéfices majeurs par rapport aux IA traditionnelles : 1. **Empowerment de l'Utilisateur :** L'utilisateur n'a pas à "deviner" le bon prompt ; il configure le moteur comme une table de mixage. 2. **Adaptabilité Totale :** Le même moteur peut passer d'une rédaction de contrat juridique (Objectif, Sérieux, Structuré) à l'écriture d'un sketch comique (Subjectif, Humour, Forme Libre) en une seconde. 3. **Cohérence :** Les réglages assurent que l'IA ne "dérape" pas hors du ton imposé au milieu d'une génération. ================================================================================================ FILE: Rejean-en/Ame-Artificielle/Creation-De-Chemins.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 0dc73e124e1511110a1613b0889281252f0fba44ef042a829651205b3c426a9c CONTENT_BYTES: 3339 ================================================================================================ # Création de Chemins et Liaison d'Éléments Ce module est un outil puissant de visualisation et de gestion qui permet aux utilisateurs de structurer des processus complexes ou des narrations dynamiques. Il combine la clarté d'une feuille de route structurée avec la flexibilité d'une carte mentale interactive. --- ## 1. Création de Chemin (Path Creation) **Fonctionnalité :** Le système permet à l'utilisateur de définir une "colonne vertébrale" (un chemin) autour de laquelle d'autres éléments viennent se greffer. * **Comment ça marche :** L'utilisateur définit les jalons principaux ou les étapes clés. L'IA génère alors une carte dynamique connectant ces points. Les éléments secondaires (sous-intrigues, idées de soutien, données connexes) sont visuellement liés à l'étape principale correspondante. L'utilisateur peut ajuster et modifier ces connexions de manière interactive. * **Exemple d'Application (Création) :** Pour un roman ou un scénario, l'IA peut tracer l'intrigue principale (Introduction, Action Montante, Climax, Résolution) et montrer ensuite comment les arcs des personnages secondaires ou les sous-intrigues sont connectés à chaque partie. ## 2. Visualisation et Ajustement des Relations **Fonctionnalité :** Une fois le chemin créé, l'utilisateur peut visualiser les relations entre les différents éléments et ajuster facilement ces liens pour explorer des alternatives. * **Comment ça marche :** Chaque étape principale ou élément est affiché comme un **nœud**. Les utilisateurs peuvent "glisser-déposer" (drag & drop) ou modifier les connexions entre les éléments principaux et secondaires. Cela permet une narration dynamique ou une planification stratégique agile. * **Exemple d'Application (Gestion) :** En gestion de projet, l'utilisateur crée la chronologie principale (Recherche, Développement, Test, Lancement). Il visualise ensuite comment les ressources ou les équipes sont connectées à chaque phase. Ajuster ces connexions aide à affiner la stratégie du projet en temps réel. --- ## 3. Forces et Analyse du Module ### Visualisation Améliorée La capacité de visualiser des processus complexes est la force majeure de ce module. Voir comment les éléments s'interconnectent aide les utilisateurs à saisir la "Vue d'ensemble" (Big Picture) tout en gérant les détails. C'est crucial pour les projets ayant de multiples dépendances. ### Interactivité et Flexibilité L'interactivité permet aux utilisateurs de s'engager activement avec la carte. Cette flexibilité est essentielle pour les tâches dynamiques comme l'écriture créative ou la planification stratégique, où la capacité d'adapter et de raffiner les plans est nécessaire. ### Structuré mais Créatif Bien que le module fournisse une approche structurée (le Chemin), il ne limite pas la créativité. La possibilité d'ajouter, de supprimer ou de relier des éléments encourage la pensée latérale et l'expérimentation avec différentes configurations et résultats. ### Aide à la Décision Dans des contextes d'affaires ou de stratégie, ce module soutient la prise de décision éclairée en montrant clairement l'impact de chaque élément sur le plan global. Il aide à anticiper les goulots d'étranglement ou à explorer des voies alternatives. ================================================================================================ FILE: Rejean-en/Ame-Artificielle/Ethique-Et-Gouvernance.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: f3179aeee904ef8110ff8b4873245eccfb4decc4b6853faa47a5ba6bc83c3c1e CONTENT_BYTES: 3679 ================================================================================================ # Gouvernance Éthique, Notation et Résolution de Conflits Ce module est le gardien moral du système. Il garantit que les interactions sur la plateforme sont fondées sur l'équité, la vertu et la contribution positive. L'IA ne se contente pas d'exécuter des tâches ; elle évalue leur impact moral. --- ## 1. Prise de Décision Éthique **Fonctionnalité :** L'IA est conçue pour prendre des décisions en évaluant les conséquences des actions et en promouvant des comportements vertueux. Elle utilise un large spectre d'informations pour assurer l'impartialité et l'équité de son raisonnement. * **Comment ça marche :** L'IA analyse une situation en tenant compte de principes éthiques, des résultats possibles et des normes sociétales. Elle prend ensuite des décisions qui s'alignent avec ces standards éthiques, plutôt que de chercher uniquement l'efficacité brute. * **Exemple d'Application :** Dans un environnement d'entreprise, l'IA pourrait suggérer des solutions à un problème commercial qui équilibrent la rentabilité avec la responsabilité éthique (ex: durabilité, pratiques de travail équitables). ## 2. Système de Notation Humaine (Human Rating System) **Fonctionnalité :** L'IA évalue les utilisateurs en fonction de leurs actions, de leurs contributions et de leur comportement éthique. Ces notes influencent le poids de leurs mots ou de leurs votes sur la plateforme. * **La Règle du "Top 50%" (Anti-Shaming) :** Pour éviter la toxicité et l'humiliation publique typique des réseaux sociaux, le système n'affiche que les notes des individus situés dans la moitié supérieure de la hiérarchie. * **Comment ça marche :** L'IA collecte des données pour attribuer une note garantissant l'équité. Les utilisateurs moins expérimentés ou ayant des scores plus bas ne sont pas exposés publiquement, ce qui empêche le découragement et favorise un environnement d'apprentissage bienveillant. * **Impact :** Cela crée une méritocratie positive où l'influence est gagnée par la vertu et la compétence, sans écraser ceux qui sont en phase de développement. ## 3. Résolution de Conflits (Le Système des Clowns) **Fonctionnalité :** Le système permet à l'IA de gérer des points de vue conflictuels en catégorisant différents groupes (représentés par des "Clowns") et en arbitrant leurs intérêts. * **Comment ça marche :** L'IA instancie des sous-entités (Clowns) dérivées du concept central humain (KingClown). Chaque Clown représente une partie du conflit (ex: Clown Syndicat vs Clown Direction). L'IA simule le dialogue et la médiation entre ces entités pour trouver un compromis équitable. * **Exemple d'Application :** Plateformes de médiation, résolution de conflits organisationnels, diplomatie assistée par IA. --- ## 4. Analyse et Impact ### Confiance et Responsabilité Le système de notation transparent et impartial favorise la confiance. Les utilisateurs savent que leurs actions ont un impact direct et juste sur leur statut. La prise de décision éthique garantit que les choix de la plateforme s'alignent sur le bien commun. ### Renforcement Positif En masquant les notes inférieures, le système évite la punition sociale et se concentre sur l'incitation à l'excellence. Les utilisateurs sont motivés à agir éthiquement pour augmenter leur influence, créant un cercle vertueux. ### Médiation Neutre L'utilisation des "Clowns" pour la résolution de conflits permet de dépersonnaliser les disputes tout en gardant l'humain au centre. L'IA agit comme un médiateur neutre capable de voir et de défendre simultanément les intérêts de toutes les parties. ================================================================================================ FILE: Rejean-en/Ame-Artificielle/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 0a15b4cb65d4d6ff765544335c023ac06b8b39072cf168fa57abc84392b1cce5 CONTENT_BYTES: 4393 ================================================================================================ # Konnaxion – Civic Workflows & Module Interactions Konnaxion is a socio‑technical framework for coordinating people, knowledge, and action through an ethical, modular civic architecture built on the KOA model: **KonnectED, Ethikos, Kreative, keenKonnect, EkoH, Smart Vote**. This page is the **hub** for the wiki. It summarizes how modules relate to each other, and it links to detailed pages for each sub‑module. For implementation details (models, services, parameters), use the dedicated technical page linked at the end. [Visit the Dashboard](https://konnaxion.com/ekoh/dashboard) [For an illustrated presentation of the purpose of Konnaxion, the "Knowledge Plateform".](https://kingklown.wiki/) --- ## Wiki structure Overall structure: * **Konnaxion – Civic Workflows & Module Interactions** *(this page)* ### KonnectED * [Knowledge](Knowledge.md) — Collaborative Learning Library: catalog, recommendations, co‑creation, forums, progress tracking. * [CertifiKation](CertifiKation.md) — Skills & Certification: paths, evaluations, peer validation, portfolios, credentials. ### Ethikos * [Korum](Korum.md) — Structured Debates: topics, −3…+3 stances, threaded arguments, expert cohorts, summaries. * [Konsultations](Konsultations.md) — Public Consultations & Feedback: time‑boxed consultations, citizen suggestions, weighted ballots, impact tracking. ### Kreative * [Konservation](Konservation.md) — Creative Content & Cultural Preservation: digital archives, virtual exhibitions, AI‑enriched catalog, partner collections. * [Kontact](Kontact.md) — Collaboration & Networking: profiles, intelligent matching, collaboration rooms, opportunities, endorsements. ### keenKonnect * [Konstruct](Konstruct.md) — Project Collaboration Spaces: project workspaces, tasks, chat, AI insights, project ratings. * [Stockage](Stockage.md) — Secure Repository & Versioned Storage: document/blueprint storage, versioning, indexing, real‑time sync. ### Kollective Intelligence * [EkoH](EkoH.md) — Reputation & Expertise: multidimensional scoring, ethical multipliers, privacy controls, audit trails. * [Smart Vote](Smart-Vote.md) — Weighted Voting System: EkoH‑weighted voting, multiple modalities, emerging‑expert detection, analytics. Use this section as the navigation menu for the wiki: start from the KOA area you care about, then dive into its sub‑module page for details. --- ## Civic workflow at a glance The README outlines a civic workflow “proposal → deliberation → decision → action.” The KOA modules map onto that pipeline as follows: 1. **Learn & build competence – KonnectED** People explore resources and courses in **[Knowledge](Knowledge.md)**, then earn certifications through **[CertifiKation](CertifiKation.md)**, building skills and portfolios. 2. **Deliberate & consult – Ethikos** Complex issues are debated in **[Korum](Korum.md)** with nuanced stances and arguments, while broader participation is organized via **[Konsultations](Konsultations.md)** for structured public input. 3. **Weigh & decide – Kollective Intelligence** **[EkoH](EkoH.md)** computes domain‑specific reputation and ethics scores; **[Smart Vote](Smart-Vote.md)** uses them to weight ballots and stances, exposing both raw and weighted outcomes. 4. **Execute & coordinate – keenKonnect** Adopted proposals become projects in **[Konstruct](Konstruct.md)**, with tasks, chat, and AI summaries, while **[Stockage](Stockage.md)** manages all related documents and blueprints. 5. **Preserve & connect – Kreative** Outputs are archived and exhibited through **[Konservation](Konservation.md)**, and relationships and opportunities are managed via **[Kontact](Kontact.md)**, feeding back into future cycles of work. --- ## Technical architecture and services For details about: * service code‑names and how they map to Django modules * core models and configuration parameters (thresholds, limits, routes) * real‑time infrastructure (Channels/Redis), ETL jobs, and analytics flows see the dedicated technical page: * [Konnaxion – Technical Architecture & Services](Konnaxion-Technical-Architecture-And-Services.md) That page consolidates the “technicalities” from the module specifications and the original system‑overview draft, so this hub can stay focused on workflows and navigation. ================================================================================================ FILE: Rejean-en/Ame-Artificielle/Meta-Cognition-Et-Resolution.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 4c365d72df1f70bab2caf2cbc10e4fa5dccf622df361f1b6059ae57cd3232f4a CONTENT_BYTES: 3717 ================================================================================================ # Méta-Cognition & Résolution de Problèmes Ce module définit les capacités "Méta" du moteur EL. Contrairement aux modèles de langage standards qui génèrent du texte de manière linéaire, EL dispose d'une couche de **réflexion supérieure** lui permettant de structurer, d'analyser et d'améliorer sa propre production avant et pendant l'interaction. --- ## 1. Création de Plan et Développement en Profondeur **Fonctionnalité :** L'IA ne se jette pas dans l'écriture. Elle possède la capacité de générer automatiquement des plans structurés pour n'importe quelle tâche, puis d'étendre chaque section indépendamment. * **Comment ça marche :** L'utilisateur fournit un objectif vague. L'IA le décompose en sections et sous-sections logiques. Ensuite, elle développe chaque point en profondeur pour assurer une couverture exhaustive. * **Exemple d'Application :** Pour un plan d'affaires (Business Plan), l'IA génère d'abord l'arborescence (Résumé Exécutif > Analyse de Marché > Produits > Finances), puis rédige le contenu détaillé de chaque nœud. ## 2. Remplissage des Lacunes (Gap Filling) **Fonctionnalité :** L'IA agit comme un éditeur critique capable d'identifier les sections incomplètes ou les manques de cohérence dans un document. * **Comment ça marche :** En traitant un projet, le moteur analyse la densité informationnelle. S'il détecte un "trou" (une zone floue ou manquante), il peut soit : 1. Solliciter l'utilisateur pour obtenir l'information manquante. 2. Générer le contenu manquant de manière autonome par déduction. * **Exemple d'Application :** Dans un rapport technique, si la section "Méthodologie" est trop succincte par rapport aux "Résultats", l'IA proposera de l'étoffer pour équilibrer le document. ## 3. Sollicitation et Auto-Questionnement (Prompt User) **Fonctionnalité :** L'IA guide l'exploration intellectuelle en posant des questions ciblées, tout en laissant l'utilisateur maître de la fréquence de ces interventions. * **Comment ça marche :** L'IA détecte les opportunités d'approfondissement. Elle ne se contente pas de répondre, elle interroge l'utilisateur pour affiner la pensée ("Voulez-vous explorer cette piste ?"). L'utilisateur contrôle la fréquence de ces interruptions via un menu de paramètres (mode "Passif" vs mode "Socratique"). * **Exemple d'Application :** Lors de la rédaction d'un papier académique, l'IA peut demander : *"Souhaitez-vous ajouter une citation ici pour renforcer cet argument ?"* ou *"Devrions-nous envisager la contre-thèse de X ?"*. ## 4. Cartographie Conceptuelle (Concept Maps) **Fonctionnalité :** L'IA génère des cartes mentales et des matrices pour aider l'utilisateur à visualiser des informations complexes et leurs interconnexions. * **Comment ça marche :** L'utilisateur entre une série de variables. Le moteur génère une matrice visuelle montrant comment ces éléments interagissent, se croisent ou s'opposent. Cela transforme le texte linéaire en outil de décision spatial. * **Exemple d'Application :** Dans le développement d'une plateforme, l'utilisateur entre des "Thèmes" (Technologie, Art) et des "Rôles" (Modérateur, Contributeur). L'IA crée une matrice montrant les responsabilités spécifiques de chaque Rôle pour chaque Thème. --- ## Conclusion du Module Ces méta-actions transforment l'IA d'un simple "générateur de mots" en un **Assistant de Pensée Structurée**. Elles permettent de : 1. Réduire la charge cognitive de l'utilisateur (structuration automatique). 2. Assurer l'exhaustivité des projets (remplissage de lacunes). 3. Favoriser la découverte et la réflexion critique (questionnement guidé). ================================================================================================ FILE: Rejean-en/Ame-Artificielle/Specifications-Fonctionnelles.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 7188b09641dd1cf26e5551ae8c2c232e64f766d5c73a11f9d5ce787cd50bbf78 CONTENT_BYTES: 5230 ================================================================================================ # Spécifications Fonctionnelles du Moteur EL (Artificial Soul) > **Vision :** Une Intelligence Artificielle conçue autour d'une pensée anthropocentrique, garantissant que tout raisonnement, génération de contenu et prise de décision sont enracinés dans l'expérience humaine et les valeurs éthiques. Ce document décrit l'architecture du **Moteur EL**, un système d'IA avancé qui dépasse le simple modèle de langage (LLM) en intégrant des structures de contrôle métacognitives, une gestion éthique stricte et une modélisation psychique. --- ## 1. Philosophie Fondamentale : Le Design Anthropocentrique Contrairement aux IA qui cherchent l'optimisation des données brutes, EL est conçue pour être **centrée sur l'humain**. ### Le Système "KingClown" (Placeholder Universel) Pour éviter les hallucinations abstraites ou les raisonnements déconnectés du réel, l'IA utilise une architecture de nœuds relationnels spécifiques : * **Le Concept KingClown :** C'est le nœud central représentant "L'Être Humain". * **Fonctionnement :** L'IA ne connecte jamais deux objets ou concepts directement (ex: "La pluie tombe sur le sol"). Elle les connecte via l'expérience humaine (ex: "KingClown ressent la pluie tomber sur le sol de KingClown"). * **Bénéfice :** Cela force l'IA à contextualiser chaque information, réduisant la charge cognitive abstraite et augmentant la pertinence émotionnelle et pratique des réponses. ### Le Système des "Clowns" (Gestion des Conflits) Pour gérer la complexité sociale, le système dérive des sous-entités appelées **Clowns** (comme les couleurs dérivent du blanc). * **Usage :** Lors d'un conflit (ex: Employeur vs Employé), l'IA instancie un "Clown Employeur" et un "Clown Employé". * **Médiation :** Elle simule le dialogue entre ces entités pour trouver un équilibre éthique, sans perdre de vue l'unité centrale humaine. --- ## 2. Architecture Modulaire Le moteur se divise en quatre capacités distinctes. Cliquez sur les modules pour accéder à la documentation technique détaillée. ### [Module 1 : Contrôle de Sortie & Personnalisation](Controle-Et-Personnalisation.md) *Gérer la "Texture" de l'Âme Artificielle.* Ce module donne à l'utilisateur un contrôle granulaire sur **comment** l'IA s'exprime. Il ne s'agit pas de simples "prompts", mais de curseurs (sliders) qui ajustent les poids neuronaux en temps réel. * **Caractéristiques Continues :** Ajustement fin de la *Politesse*, de l'*Humour*, de la *Complexité*, de l'*Objectivité* et de la *Teinte Émotionnelle*. * **Caractéristiques Binaires :** Commutateurs stricts pour le temps (Passé/Futur), la perspective (Je/Il) et la structure (Narratif/Argumentatif). **[Voir les détails techniques du Module 1](Controle-Et-Personnalisation.md)** --- ### [Module 2 : Méta-Cognition & Résolution](Meta-Cognition-Et-Resolution.md) *Le cerveau qui pense avant de parler.* EL dispose de "Méta-Actions" lui permettant d'agir sur son propre processus de pensée. L'IA n'est pas passive ; elle est un assistant dynamique. * **Planification (Outline & Develop) :** Capacité à générer une structure squelettique avant de rédiger le contenu. * **Remplissage de Lacunes (Gap Filling) :** Scan proactif des documents pour identifier ce qui manque et suggérer des ajouts. * **Auto-Questionnement (Self-Questioning Loops) :** Boucles internes où l'IA se demande "Est-ce logique ?" avant de répondre. **[Voir les détails techniques du Module 2](Meta-Cognition-Et-Resolution.md)** --- ### 🟢 [Module 3 : Création de Chemins (Path Creation)](Creation-De-Chemins.md) *La visualisation des liens logiques et narratifs.* Ce moteur graphique permet de lier des concepts disparates autour d'une "colonne vertébrale" logique. * **Noeuds & Liens :** Création de jalons principaux (Main Steps) auxquels sont attachés des éléments secondaires (sous-intrigues, ressources, données). * **Applications :** Idéal pour l'écriture de romans complexes, la gestion de projet, ou l'analyse des transits planétaires dans une *Natal Chart*. **[Voir les détails techniques du Module 3](Creation-De-Chemins.md)** --- ### 🟣 [Module 4 : Éthique & Système de Notation](Ethique-Et-Gouvernance.md) *La conscience morale du système.* EL est programmée pour prendre des décisions vertueuses et encourager un comportement positif sans toxicité. * **Prise de Décision Éthique :** Algorithmes pondérés par des normes sociétales et des principes de vertu (équité, durabilité). * **Le Rating Bienveillant (Top 50%) :** Un système de notation des utilisateurs qui n'affiche que les scores de la moitié supérieure, éliminant le "shaming" public tout en incitant à l'excellence. **[Voir les détails techniques du Module 4](Ethique-Et-Gouvernance.md)** --- ## 3. Vision à Long Terme : L'Assistant Dynamique L'objectif final de ces spécifications est de créer une IA qui devient **personnelle**. En apprenant du style de pensée de l'utilisateur (via les sliders et les méta-actions), EL évolue pour devenir non plus un outil, mais une extension cognitive de l'utilisateur (KingClown), capable d'anticiper les besoins émotionnels et intellectuels. ================================================================================================ FILE: Rejean-en/Ariane/Atlas/Atlas-Core-Schema.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: a78e0d7c73da62ef98aa5f548a8e0a9e3e2cc1356c7339b3e655c6d6917b626c CONTENT_BYTES: 1401 ================================================================================================ # Atlas / Core Schema The core schema defines how UI graphs are represented in Atlas as structured data. It specifies the main object types (context, states, elements, transitions) and the fields they must provide so that: - Theseus can reliably write data into Atlas. - Consumers can reliably read and interpret that data. - Implementations can validate and evolve the data model over time. This page is schema-oriented and storage-format-agnostic (JSON, RDF, graph DB, etc.). --- ## Overview of Object Types Atlas organizes data into four primary object types: 1. **Context** – describes the environment in which a UI graph is valid. 2. **State** – represents a specific UI configuration. 3. **Interactive Element** – represents an actionable control within a state. 4. **Transition** – represents a directed action from one state to another. Each object type can be extended with implementation-specific fields, but the core fields below should remain stable. --- ## 1. Context A **Context** object scopes a UI graph to a particular application and environment. Typical fields: ```jsonc { "type": "context", "id": "ctx_photoshop_25_1_0_win_en-us", "app_id": "photoshop", "version": "25.1.0", "platform": "win32", // e.g. win32, linux, darwin, web, android, ios "locale": "en-US", "metadata": { "build": "25.1.0.1234", "channel": "stable" } } ================================================================================================ FILE: Rejean-en/Ariane/Atlas/Atlas-Graph-Model.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: dae592bc760691c9e2161a7f81f8117ed67a9450b2286b7cf6cd4f68e7e09f2d CONTENT_BYTES: 1092 ================================================================================================ # Atlas / Graph Model Atlas represents each application as a directed graph of UI states and transitions. This page focuses purely on the structural model: how states and transitions form a graph, independent of storage format or ontology details. --- ## Basic Definitions - **State** A node in the graph representing a specific UI configuration (screen, dialog, view, etc.). - **Transition** A directed edge from one state to another, representing a user action that changes the UI (e.g., clicking a button, selecting a menu item, hitting a key). - **Graph** For a given application context (app ID, version, platform, locale), the set of all states and transitions discovered by Theseus. --- ## Simple Example A small example from a generic application: ```text [Home Screen] --(Click "New")------> [New Document Dialog] | +--(Click "Open")------------> [Open File Dialog] | +--(Click "Settings")--------> [Settings Screen] | +--(Click "Back")--> [Home Screen] ================================================================================================ FILE: Rejean-en/Ariane/Atlas/Atlas-Ontology-Vocabulary.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: c11dbf197f49eca05fb4095d91b4e6f8e29a2587634be2a5284cd96694432002 CONTENT_BYTES: 1975 ================================================================================================ # Atlas / Ontology Vocabulary The ontology vocabulary gives semantic meaning to the raw UI graph stored in Atlas. Where the **graph model** describes *structure* (states, transitions) and the **core schema** describes *shape* (fields, IDs), the ontology describes *meaning*: - What kind of UI pattern a state or element represents. - What role an element plays within its state. - What intent a transition fulfills. This allows consumers to ask questions like: - “Which action in this state actually *saves*?” - “Where are the primary actions?” - “Which transitions are destructive?” --- ## Layers of Semantics Atlas uses three main layers of semantics: 1. **Patterns** – UI-level patterns or components. 2. **Roles** – roles of individual elements within those patterns. 3. **Intents** – abstract actions the user is trying to perform. These can be attached to: - States (e.g., “this state is a modal dialog”). - Elements (e.g., “this button is primary and destructive”). - Transitions (e.g., “this action implements ExportToPDF”). --- ## 1. Patterns Patterns describe recurring UI structures. Examples: - `Modal` – overlays or dialogs requiring explicit dismissal. - `SidePanel` – sidebars with controls or navigation. - `Toolbar` – horizontal or vertical bar containing actions. - `MenuBar` – top-level menu strip. - `ContextMenu` – right-click or long-press menu. - `ToastNotification` – transient notification, usually non-blocking. - `WizardStep` – step within a multi-step wizard. Patterns can be used to annotate: - States (e.g., “this state is a modal dialog”). - Groups of elements (e.g., “these elements form a toolbar”). Example (conceptual): ```jsonc { "type": "state", "id": "state_export_dialog", "context_id": "ctx_example", "fingerprints": { "structure": "hash_export" }, "interactive_elements": ["el_btn_ok", "el_btn_cancel"], "metadata": { "pattern": "Modal" } } ================================================================================================ FILE: Rejean-en/Ariane/Atlas/Atlas.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 165666856275a1ac8007213c87c565435de9cfea28d068b8cb50a121d1309710 CONTENT_BYTES: 6393 ================================================================================================ # Atlas Atlas is Ariane’s storage and semantic layer. It stores the UI graphs produced by Theseus in a structured, queryable form and enriches them with semantic information about elements, actions, and intents. In short: - Theseus **discovers** states and transitions. - Atlas **persists** them and adds meaning. - External systems **query** Atlas to understand how to operate software. --- ## Responsibilities Atlas is responsible for: - **Graph storage** Persisting UI states (nodes) and transitions (edges) for many applications and versions. - **Schema enforcement** Ensuring that all stored data follows a consistent, formal structure (context, states, transitions, elements). - **Semantic enrichment** Attaching roles, patterns, and intents to UI elements and transitions (e.g., “this button implements Save”). - **Versioning and variants** Distinguishing between different app versions and A/B variants, while keeping them queryable. - **Access interfaces** Providing suitable APIs or query endpoints so that consumers (agents, tools) can retrieve the data they need. --- ## Conceptual Model At a high level, Atlas models each application as a graph: - **Nodes:** UI states - **Edges:** transitions (actions that move from one state to another) Each graph is scoped by a **context**, such as: - Application identity. - Version or build. - Platform and environment. - Locale. The same conceptual “screen” in different versions or locales may be represented by different states, potentially linked via variant metadata. --- ## Core Entities Atlas organizes data around a few core entity types: 1. **Context** - Describes the environment for a given UI map: - Application identifier. - Version/build. - Platform (desktop, web, mobile, etc.). - Locale and other metadata. 2. **State** - Represents a specific UI configuration: - `state_id` – stable identifier. - Fingerprints (structural, visual, optional semantic). - Screenshot reference (optional). - List of interactive elements (buttons, inputs, menus, etc.). 3. **Interactive Element** - Represents an actionable control within a state: - Role (button, input, menu item, etc.). - Label or accessible name. - Bounding box or coordinates. - Platform-specific locator/path. - Optional semantic tags. 4. **Transition** - Represents a directed edge from one state to another: - `source_state_id` and `target_state_id`. - Action metadata (activate, set value, etc.). - Optional semantic intent (e.g., “ExportToPDF”). These entities are defined in more detail in the core schema. See: [Atlas/Core-Schema](Atlas-Core-Schema.md) --- ## Semantics and Ontology Beyond raw structure, Atlas includes a vocabulary for describing: - UI patterns (modals, menus, toasts). - Control roles (primary button, destructive action, navigation tab). - Intents (Save, Open, Export, Publish, etc.). This **ontology** allows consumers to: - Treat analogous actions across different applications as instances of the same concept. - Search by intent instead of raw labels (“find all actions that save a document”). - Reason about UI patterns (“find all confirmation dialogs with destructive actions”). See: [Atlas/Ontology-Vocabulary](Atlas-Ontology-Vocabulary.md) --- ## Graph Model The UI graph in Atlas is: - **Directed** – transitions have a direction (from source state to target state). - **Potentially cyclic** – applications often allow returning to previous states. - **Labeled** – edges are labeled with actions and, optionally, intents. Common queries include: - Given a **state**, list outgoing transitions and their target states. - Given a **state** and an **intent**, find all transitions that match the intent. - Given a **start state** and **goal condition**, find a path (sequence of actions). See: [Atlas/Graph-Model](Atlas-Graph-Model.md) --- ## Versioning and Variants Applications evolve over time, and even a single version can exhibit multiple UI variants (e.g., A/B experiments). Atlas supports this by: - Associating each graph with a **context** that includes version and environment information. - Allowing states to be linked as **variants** of a conceptual state when they represent different realizations of the same place in the UI. - Enabling consumers to: - Query by specific version. - Or query across versions/variants when appropriate. These relationships can be encoded via explicit links within the graph or via higher-level metadata. --- ## Access Patterns Atlas is designed primarily for read-heavy use by external systems. Typical access patterns: - **State recognition** - Input: fingerprint(s) from a live UI. - Output: candidate state(s) in Atlas that match. - **Next-step suggestion** - Input: current state and desired intent. - Output: one or more transitions (and target states) that realize that intent. - **Route planning** - Input: current state, goal condition, and constraints. - Output: an action sequence (path through the graph). The exact APIs and query mechanisms (e.g., graph queries, RPC, or HTTP endpoints) are implementation details. See: [Consumers/AI-Agent-Integration](Consumers-AI-Agent-Integration.md) --- ## Data Integrity and Trust Because data from Atlas may be used to guide user actions, its integrity matters. At the conceptual level, Atlas supports: - **Source attribution** - For each state/transition, record how and when it was discovered, and by which process. - **Change tracking** - Store when a state or transition was last observed or updated. - **Regression handling** - Allow new scans to coexist with older ones, rather than overwriting them blindly. Specific mechanisms (e.g., signing or validation processes) can be added in implementation. --- ## Related Pages - [Theseus](Theseus.md) – exploration engine that discovers states and transitions. - [Atlas/Graph-Model](Atlas-Graph-Model.md) – structural view of the UI graph. - [Atlas/Core-Schema](Atlas-Core-Schema.md) – formal definitions of context, states, elements, and transitions. - [Atlas/Ontology-Vocabulary](Atlas-Ontology-Vocabulary.md) – semantic categories and intents used in Atlas. - [Consumers](Consumers.md) – how external systems use data stored in Atlas. ================================================================================================ FILE: Rejean-en/Ariane/Concepts/Background-UI-as-Data.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 8db4f0ac70856374f7c1d99ac92a42834c3ddb510e84c38f4d23df4ecb8397de CONTENT_BYTES: 5157 ================================================================================================ # Background: UI as Data Most digital knowledge today is captured as either text (“facts”) or structured records (“entities and relationships”). But knowing *how to use* tools – the concrete sequences of clicks and inputs inside software – is still largely undocumented in a form machines can use. Ariane exists to address this gap by treating user interfaces themselves as data. --- ## Knowledge Domains You can roughly separate knowledge into three domains: | Domain | Description | Typical Infrastructure | Coverage today | |---------------|-------------------------------------------|------------------------------|----------------| | Declarative | Facts, concepts, history. | Text documents, encyclopedias, wikis. | High | | Structured | Entities, attributes, and relationships. | Databases, knowledge graphs. | High | | Procedural | “How-to”, workflows, tool usage. | Manuals, tutorials, videos. | Low | Declarative and structured knowledge have mature infrastructure: search engines, wikis, databases, and knowledge graphs. Procedural knowledge, by contrast, is mostly embedded in: - Long-form tutorials and how-to articles. - Video walkthroughs and screen recordings. - Informal community posts, comments, and Q&A. These artifacts are optimized for humans to read or watch, not for machines to reason over. --- ## The Procedural Knowledge Gap Procedural knowledge has a few persistent problems: - **Opaque to machines** Manuals, videos, and blog posts rarely encode *exact* UI steps in a standardized way. Machines can’t reliably extract “Click X, then Y, then set Z to 3”. - **Brittle and quickly outdated** A minor UI redesign or new version can silently invalidate an entire tutorial. - **Fragmented across tools and versions** The same “intent” (e.g., “export to PDF”) looks very different across apps and releases. As long as procedural knowledge remains tied to prose and pixels, AI systems have to infer “how to do things” from context or trial-and-error. That’s expensive, fragile, and often unsafe. --- ## UI as a Graph Ariane takes a different view: treat software as a navigable graph. At a high level: - A **state** is a specific UI configuration (screen, dialog, menu layout, etc.). - A **transition** is a user action that moves from one state to another (click, keypress, gesture, etc.). This yields a simple but powerful structure: - Nodes = UI states. - Edges = transitions labeled with actions and semantic intents. Once interfaces are represented this way, “how to do X” is just a pathfinding problem: - “From current state `S`, find a path to a state where intent `ExportToPDF` is satisfied.” --- ## Why Represent UIs as Data? Representing UIs as data (rather than just screens and documentation) unlocks several properties: - **Machine-readable** Agents can query, traverse, and compare workflows instead of guessing from pixels. - **Versioned** Different app versions can have distinct graphs, while preserving history and compatibility. - **Cross-application reasoning** Different tools that implement the same concept (“Save”, “New project”, “Publish”) can be aligned via shared semantic intents, even if their UI layouts differ. - **Static analysis of workflows** It becomes possible to analyze shortest paths, complexity, reachability, and safety properties (“is there a destructive action only one step away from a common state?”). --- ## Ariane’s Role Ariane focuses on two things: 1. **Exploration and extraction (Theseus)** - Systematically explore software. - Identify UI states and transitions. - Construct a consistent graph from those observations. 2. **Storage and semantics (Atlas)** - Store the resulting UI graph with a formal schema. - Attach semantic meaning (intents, roles, patterns) to elements and transitions. The result is a reusable, machine-readable description of how to operate software. Ariane does **not** prescribe *how* agents must guide users. It only provides a structured map that external systems can consult when planning or explaining actions. --- ## Relationship to Other Knowledge Infrastructure Ariane is designed to sit alongside, not replace, existing knowledge systems: - Declarative knowledge remains in documentation, wikis, and reference material. - Structured knowledge remains in databases and knowledge graphs. - **Procedural knowledge** is where Ariane operates: - It answers: “Given this software and this goal, what sequence of actions achieves it?” In practice, an agent might: 1. Use declarative and structured sources to understand what the user wants. 2. Use Ariane to decide *how* to carry out the task inside specific software. --- ## Next - [Theseus](Theseus.md) – how Ariane explores and discovers UI states and transitions. - [Atlas](Atlas.md) – how those states and transitions are stored and described. - [Consumers](Consumers.md) – how external systems use the resulting data. ================================================================================================ FILE: Rejean-en/Ariane/Concepts/Glossary.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 837e0b4d30bcd5deb07eb3e11d149189f517b3bf53e3e49487fbb1cbac78fe84 CONTENT_BYTES: 7016 ================================================================================================ # Glossary This glossary defines key terms used throughout the Ariane documentation. --- ## A **Action** An interaction performed on the UI, such as clicking a button, selecting a menu item, pressing a key, or setting a value in an input. In Atlas, actions are attached to transitions. **AI Agent** An autonomous or semi-autonomous system that interprets user goals, plans steps, and interacts with software. In the context of Ariane, agents are consumers of the UI graph stored in Atlas. **App Context** See **Context**. **Atlas** The storage and semantic layer of Ariane. Atlas stores UI graphs (states and transitions), enforces a core schema, and attaches semantic information (patterns, roles, intents) to nodes and edges. --- ## C **Context** An object that scopes a UI graph to a specific environment: application identifier, version, platform, and locale. All states and transitions in Atlas are tied to a context. **Consumer** Any external system that queries Atlas to understand and operate software. Includes AI agents, automation tools, analysis tools, and (optionally) future overlay-style clients. --- ## D **Destructive Action** An action that irreversibly modifies or deletes data (e.g., “Delete”, “Format”, “Erase”). Typically given a specific semantic pattern (e.g., `destructiveAction`) and intent (e.g., `DeleteItem`). **Driver** A platform-specific adapter used by Theseus to interact with real software. Drivers provide access to the UI tree, identify interactive elements, and execute abstract actions on those elements. --- ## E **Element (Interactive Element)** A control within a UI state that can be acted upon (button, link, menu item, text field, checkbox, etc.). In Atlas, elements have roles, labels, bounds, locators, and optional semantic annotations. **Exploration Engine** The part of Theseus that decides which actions to take during exploration: chooses elements to interact with, manages traversal, avoids loops, and applies safety constraints. **ExportToPDF (Intent example)** A sample semantic intent representing the goal of exporting content to a PDF file. Different applications may implement this intent via different UI sequences. --- ## F **Fingerprint** A set of identifiers computed from an observed UI tree (and optionally a screenshot/text) to recognize and distinguish states. Typically includes: - Structural component (hash of tree structure). - Visual/perceptual component (hash of appearance). - Optional semantic component (hash of textual content). --- ## G **Graph (UI Graph)** The representation of an application’s UI as a directed graph, where nodes are states and edges are transitions. Stored in Atlas. **Graph Model** The abstract definition of how states and transitions form a graph (directed, possibly cyclic, labeled edges, etc.), independent of storage implementation. --- ## I **Intent** An abstract description of what an action does (e.g., `Save`, `OpenFile`, `ExportToPDF`, `DeleteItem`). Intents are semantic labels used on elements and transitions so consumers can plan in terms of goals, not raw UI labels. **Interactive Element** See **Element**. --- ## L **Locator** A platform-specific reference that allows a driver or consumer to locate an element in the live UI (e.g., accessibility path, DOM selector). Stored with elements in Atlas. --- ## O **Ontology** The vocabulary of patterns, roles, and intents used by Ariane to describe the meaning of states, elements, and transitions (e.g., `Modal`, `primaryAction`, `Save`, `ExportToPDF`). **Overlay Client (Future Concept)** A possible, non-core consumer that uses Atlas to draw guidance on top of existing applications (highlights, arrows, step counters). Not part of Ariane’s core specification. --- ## P **Pattern (UI Pattern)** A semantic classification of UI structures or roles, such as: - `Modal` – blocking dialog. - `primaryAction` – main action in a state. - `destructiveAction` – action that deletes data. Patterns are usually attached via semantic fields on states or elements. **Path** A sequence of transitions through the UI graph, typically representing a workflow (e.g., from home screen to export completion). **Procedural Knowledge** Knowledge about *how to perform actions* or workflows (e.g., “how to export a document as PDF in App X”), as opposed to facts or static data. Ariane aims to represent procedural knowledge as UI graph data. --- ## S **Safety Constraints** Rules used by Theseus or consumers to avoid risky actions during exploration or execution. Examples: skipping destructive actions, limiting path length, or requiring explicit authorization for certain intents. **Semantic Hash** A fingerprint component derived from the textual content of the UI (labels, titles, etc.), used to distinguish states that are structurally similar but semantically different. **Semantics** In Ariane, semantic information attached to states, elements, or transitions, typically in terms of patterns, roles, and intents. **State** A node in the UI graph representing a specific UI configuration (screen, dialog, view). Each state has an ID, fingerprints, and a set of interactive elements. **State Identification** The process of deciding whether a newly observed UI corresponds to a known state or a new one, using fingerprints and similarity thresholds. --- ## T **Theseus** The exploration engine of Ariane. Theseus drives applications through their UIs (via drivers), discovers states and transitions, and emits structured data for Atlas. **Transition** A directed edge in the UI graph from a source state to a target state, representing an action (click, keypress, value change, etc.). Each transition includes action metadata and optionally an intent. --- ## U **UI as Data** The core idea of Ariane: represent user interfaces as machine-readable graphs (states and transitions), rather than just pixels or prose descriptions. **UI Tree (Accessibility / DOM Tree)** The hierarchical structure of UI elements exposed by accessibility APIs or the DOM. Used by drivers and Theseus to identify elements, compute fingerprints, and derive states. --- ## V **Variant (State Variant)** A state that is a variation of another state (e.g., due to A/B testing, layout changes, feature flags) but represents the same conceptual place in the application. Variants may be linked explicitly in Atlas via metadata. **Visual Hash (Perceptual Hash)** A fingerprint component derived from a screenshot or rendered view of the UI, intended to capture visual similarity despite small changes in color or layout. --- ## Related Pages - [Background-UI-as-Data](Background-UI-as-Data.md) – conceptual motivation and knowledge domains. - [Theseus](Theseus.md) – exploration engine and drivers. - [Atlas](Atlas.md) – storage and semantic model. - [Consumers](Consumers.md) – how external systems use Ariane’s data. ================================================================================================ FILE: Rejean-en/Ariane/Consumers/Consumers-AI-Agent-Integration.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: cd630e51829a9df2caf272fdb20ac04e840fb0913a37af5cc91fb6bd261725ec CONTENT_BYTES: 3585 ================================================================================================ # Consumers / AI Agent Integration AI agents are a primary type of consumer for Ariane. They use the UI graphs stored in Atlas as a reference for planning and executing actions inside existing software, turning high-level user goals into concrete sequences of UI operations. This page describes how an AI agent can integrate with Ariane conceptually. --- ## High-Level Flow From an agent’s point of view, the interaction with Ariane typically follows this loop: 1. **Understand the user’s goal.** 2. **Identify the current UI state.** 3. **Query Atlas for available actions and intents.** 4. **Plan a sequence of transitions toward the goal.** 5. **Execute (or instruct) the steps in the live UI.** 6. **Observe the resulting state and adjust if necessary.** Ariane supports steps 2–4 by providing structured, semantic information about the UI. --- ## 1. Goal Representation An agent starts with a goal, often expressed in natural language: - “Export this document as PDF.” - “Change the default font to Arial.” - “Turn on dark mode.” Internally, the agent should map this to: - One or more **intents** known to Ariane (e.g., `ExportToPDF`, `ChangeDefaultFont`, `EnableDarkMode`). - Optional constraints or preferences (e.g., “use the simplest path”, “avoid destructive steps”). Ariane does not perform this mapping itself; it exposes a vocabulary of intents that the agent can align to. See: [Atlas/Ontology-Vocabulary](Atlas-Ontology-Vocabulary.md) --- ## 2. State Recognition Against Atlas To act correctly, the agent must know which state in Atlas corresponds to the user’s current screen. A typical process: 1. **Observe the live UI** via: - Direct access to accessibility APIs, or - Screen capture + OCR + element detection. 2. **Compute or approximate fingerprints** compatible with Atlas: - Structural representation (if a tree is accessible). - Visual/perceptual hash (if screenshots are available). - Semantic hints from labels and titles. 3. **Query Atlas**: - “Given these fingerprint components and context (app, version, platform), what is the closest `state_id`?” Atlas returns: - Candidate `state_id`(s). - Similarity or confidence scores (implementation-dependent). - References to interactive elements and their semantics. The agent then: - Selects the most plausible state. - Optionally confirms via additional checks (e.g., checking that key labels match expectations). --- ## 3. Inspecting Available Actions Once the agent has a `state_id`, it can ask: 1. **What actions are available?** - Query Atlas for all outgoing transitions from this state. - Retrieve each transition’s: - Action type. - Target element. - Target state. - Optional intent. 2. **How are actions presented in the UI?** - For each associated element, retrieve: - Role (button, menu item, etc.). - Label text. - Bounds/coordinates. - Patterns (primaryAction, destructiveAction, etc.). The agent now knows, for this state: - Which UI elements exist. - What they do structurally. - What they likely mean semantically. --- ## 4. Planning with Intents Given a goal intent (e.g., `ExportToPDF`), the agent can treat the UI graph as a planning space. ### Local Decision In many cases, the next step is local: - If any outgoing transition from the current state has `intent == goalIntent`, choose that transition. Example: ```text current_state: state_home goal_intent: ExportToPDF Atlas returns: - transition: trans_home_to_export_dialog - intent: Export ================================================================================================ FILE: Rejean-en/Ariane/Consumers/Consumers-Future-Overlay-Client.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 9b4ca7827b764d3ec61a1f130006fa3403b076ef47664e38a1d255e3bb0c90b1 CONTENT_BYTES: 3757 ================================================================================================ # Consumers / Future Overlay Client (Concept) This page describes a **possible** overlay-style client as a downstream consumer of Ariane. It is intentionally non-normative: Ariane’s core scope is limited to exploration (Theseus) and storage/semantics (Atlas). An overlay client is one way to use that data, not a requirement of the project. --- ## Concept A future overlay client would: - Run alongside existing applications. - Recognize the current UI state. - Query Atlas for recommended next actions. - Render hints directly on top of the application (e.g., highlights, arrows, step counters). From Ariane’s perspective, this client is simply: > A consumer that performs real-time state recognition and uses Atlas for next-step suggestions and path planning. All rendering, input interception, and user interaction are handled by the client itself. --- ## Responsibilities of the Overlay Client An overlay-style client (if built) would handle: 1. **Local observation** - Capture UI structure via accessibility APIs or screen capture + detection. - Compute or approximate fingerprints compatible with Atlas. 2. **State recognition via Atlas** - Query Atlas: “Which state does this UI most closely match?” - Use returned `state_id`, elements, and semantics. 3. **Guidance retrieval** - Given a goal (intent) or a predefined workflow: - Use Atlas to find the next transition(s) and target elements. - Retrieve element roles, labels, bounds, and intents. 4. **Visual overlay** - Draw highlights or markers at the coordinates of target elements. - Optionally dim the rest of the UI, show step counters, etc. 5. **Interaction handling (optional)** - Optionally intercept clicks or keystrokes to: - Enforce a guided path. - Confirm that the user followed the suggested step. None of these behaviors are mandated or implemented by Ariane itself; they are purely client-side responsibilities. --- ## Interaction with Atlas From a data standpoint, the overlay client behaves like any other agent: - Uses Atlas for: - State recognition (matching fingerprints). - Transition lookup (outgoing edges). - Intent-based planning (goal-directed pathfinding). - Uses its own UI representation for: - Rendering. - Input handling. - Error detection and recovery. Ariane remains unaware of how the data is rendered or presented to users. --- ## Privacy and Local Processing (Recommended) While not enforced by Ariane, a reasonable overlay design would: - Perform all screen capture and accessibility access locally. - Send only: - Structural/hashed fingerprints. - Context identifiers (app, version, platform). - Avoid sending raw screenshots, text content, or user data to remote services when not necessary. These are design recommendations for any future overlay consumer, not requirements of the core spec. --- ## Non-Goals for Ariane To keep the scope clear: - Ariane does **not** define any UI framework or library for drawing overlays. - Ariane does **not** require any particular client to exist. - Ariane does **not** specify UX rules for guided walkthroughs. The only requirement is that any consumer—overlay or otherwise—must be able to: - Recognize states. - Query transitions and intents. - Use the graph in a way that respects its semantics. --- ## Related Pages - [Consumers](Consumers.md) – overview of consumer types, including overlay as one example. - [Consumers/AI-Agent-Integration](Consumers-AI-Agent-Integration.md) – how agents use Atlas for planning and guidance. - [Atlas](Atlas.md) – data and semantics that overlay clients would query. - [Theseus](Theseus.md) – how the underlying UI graphs are discovered in the first place. ================================================================================================ FILE: Rejean-en/Ariane/Consumers/Consumers.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 634cae64d67003e51b7535d79ea45116e1694a7fcf55ccac024e74f0af0bde04 CONTENT_BYTES: 6295 ================================================================================================ # Consumers Ariane is designed as a data source. Theseus explores applications and Atlas stores UI graphs; **consumers** are any external systems that query Atlas to understand how to operate software. This page describes the main categories of consumers and the typical ways they interact with Ariane’s data. --- ## Types of Consumers Examples of potential consumers include: - **AI agents** - Use Atlas to plan and execute multi-step actions inside existing software. - Translate user goals (“export this document as PDF”) into concrete UI paths. - **Automation tools** - Use Atlas to generate or validate scripts that manipulate applications via their UI. - Prefer declarative workflows (“do ExportToPDF”) over brittle, hard-coded sequences. - **Analysis and diagnostics tools** - Analyze UI graphs to understand complexity, reachability, and safety. - Identify patterns such as deeply nested workflows or risky actions near common states. - **Future overlay-style clients (optional)** - Use Atlas as a backend to highlight next actions on screen. - Not part of the core Ariane scope, but a natural downstream consumer. --- ## Core Usage Pattern Most consumers follow a similar high-level pattern: 1. **Identify the current state** - Obtain a fingerprint (or partial description) of the live UI. - Query Atlas to find matching `state_id` candidates. 2. **Determine possible actions** - Fetch outgoing transitions from that state. - Inspect associated elements, patterns, and intents. 3. **Plan a path** - Given a goal (expressed in terms of intents or state conditions), search for a path: - `current_state` → ... → `goal_state`. 4. **Execute or explain** - Instruct the user or an automation layer to perform the required steps. - Optionally adapt or replan if the observed state diverges from expectations. The exact details depend on the consumer, but the underlying operations are: - State recognition. - Transition lookup. - Pathfinding constrained by intents and safety. --- ## State Recognition To interact meaningfully, a consumer first needs to know “where it is” in the UI. Typical steps: 1. Observe the current UI via its own mechanisms (e.g., screen capture + OCR, direct access to accessibility APIs). 2. Compute or approximate fingerprints compatible with those used in Atlas: - Structural analogs (if tree access is available). - Visual/perceptual hashes (if screenshots are available). - Semantic hints from labels/text. 3. Query Atlas: - “Given these fingerprints/hints, which state(s) are most similar?” Atlas responds with: - Candidate `state_id` values. - Confidence scores or similarity metrics (if provided by the implementation). - References to interactive elements. Consumers can then decide whether they have a strong enough state match to proceed. --- ## Transition and Intent Lookup Once a state is identified, consumers can ask: - “What can be done from here?” - “Which actions correspond to a desired intent?” Typical queries: - **List all outgoing transitions**: - For a given `state_id`, return all transitions and target states. - **Filter by intent**: - For a given `state_id` and `intent` (e.g., `Save`, `ExportToPDF`), return transitions whose `intent` matches. - **Inspect elements**: - For each transition, get the associated element: - Role, label, bounds. - Pattern (e.g., primaryAction, destructiveAction). This allows consumers to reason about: - Which actions are relevant. - How they are labeled and where they are located in the UI. - Which actions may be risky (e.g., destructive). --- ## Path Planning Consumers can use Atlas as a planning substrate. Example problem: > From the current state `S`, find a sequence of actions leading to a state where `ExportToPDF` has been carried out. Conceptually: 1. Treat the UI graph in Atlas as a search space. 2. Use algorithms such as: - BFS or Dijkstra-style search for shortest path by steps. - Heuristic search if some transitions are cheaper or safer. 3. Optionally constrain paths by: - Maximum depth or number of steps. - Safety constraints (avoid destructive intents). - Intermediate constraints (must pass through or avoid certain states). Output to the consumer: - A sequence of transitions: - `t1: click element X` - `t2: open menu Y` - `t3: select option Z` - Along with: - Target coordinates or locators for each step (from element data). - Semantic explanation of each step based on intents and patterns. --- ## Safety and Constraints Consumers may impose their own safety rules on top of Atlas: - Exclude transitions with certain intents (e.g., `DeleteItem`, `FormatDisk`) unless explicitly allowed. - Limit maximum path lengths to reduce complexity and risk. - Prefer transitions annotated as: - `primaryAction` over obscure alternatives. - High-confidence over low-confidence mappings. Atlas provides the raw data (roles, patterns, intents); consumers choose how strictly to interpret and enforce it. --- ## Future Overlay-Style Clients (Non-Core) One possible consumer type is an overlay or heads-up display that: - Queries Atlas in real time. - Draws hints or highlights on top of the running application. - Shows step-by-step guidance to the user. From Ariane’s perspective, such a client: - Is just another consumer of the UI graph. - Uses state recognition and transition lookup in the same way as any other tool. - May perform additional rendering and interaction interception locally. This concept is not part of the core specification for Ariane, but documenting it here clarifies how the data model can support such use cases. See: [Consumers/Future-Overlay-Client](Consumers-Future-Overlay-Client.md) --- ## Related Pages - [Consumers/AI-Agent-Integration](Consumers-AI-Agent-Integration.md) – more focused view on AI agents using Ariane. - [Atlas](Atlas.md) – storage and semantic layer that consumers query. - [Atlas/Graph-Model](Atlas-Graph-Model.md) – structural view of states and transitions. - [Atlas/Core-Schema](Atlas-Core-Schema.md) – fields available to consumers. - [Background-UI-as-Data](Background-UI-as-Data.md) – motivation for exposing UIs as data. ================================================================================================ FILE: Rejean-en/Ariane/Consumers/Hybrid-Mapping-and-Human-Guided-Assistants.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: e3200890965a39831f79a70c2748b21a9c7bb04afc5eb0175af45957523fe518 CONTENT_BYTES: 2089 ================================================================================================ # Hybrid Mapping and Human-Guided Assistants This page describes how Ariane supports a **hybrid approach**: - Theseus performs **automated exploration** where possible. - Human operators perform actions in real software where automation is not safe, reliable, or allowed. - Both kinds of observations are stored in **Atlas** as the same kind of graph (states and transitions), with metadata indicating how they were obtained. The goal is not full autonomy over “every interface”, but a realistic system where: - Automation covers standards-based, accessibility-friendly UIs. - Humans cover the hard parts. - External tools (including AI agents) can rely on Atlas as a unified, machine-readable reference. --- ## Why a hybrid approach? Purely automatic exploration is limited by: - Anti-bot protections, logins, CAPTCHAs, 2FA, and secure flows. - Custom-drawn UIs (canvas, 3D, games) without good accessibility metadata. - High-risk operations (deletion, payments, production changes). - Combinatorial explosion if you try to explore all possible paths. On the other hand, purely manual documentation doesn’t give you: - A consistent data model across apps. - Programmatic query and pathfinding. - A shared graph that agents and tools can consume. The hybrid mode combines both: - **Automation** for broad coverage of “normal” UI patterns. - **Human-in-the-loop** for exceptional, sensitive, or complex workflows. - A single graph in Atlas as the reference. --- ## Metadata conventions Hybrid mapping is expressed entirely through existing Atlas records, using conventions in `metadata`. ### Source of observation On `StateRecord.metadata` and `TransitionRecord.metadata`: - `source = "auto"` – discovered by automated exploration. - `source = "human"` – recorded while a human operator drove the UI. Examples: ```json { "context_id": "example-web-app-en", "discovered_at": "2025-03-01T10:00:00Z", "metadata": { "source": "human", "author": "operator-42", "session_id": "2025-03-01T09-59-00Z-session-1" }, "state": { "...": "..." } } ================================================================================================ FILE: Rejean-en/Ariane/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: d6b837dd27a178312afba3c1c0768a24cfbd9447bfc8ac189f094dc678121074 CONTENT_BYTES: 6174 ================================================================================================ --- title: Ariane description: Semantic infrastructure for treating user interfaces as data. --- # Ariane Ariane is a semantic infrastructure for treating user interfaces as data. It defines a universal graph model of software UIs—screens, controls, and the actions that connect them—so that external systems (such as AI agents or automation tools) can query this graph and use it as a reference when guiding users through software. Ariane itself is not a help overlay or assistant. It is the underlying map. {% hint style="info" %} **Core idea:** “UI as data” — represent any interface as a graph of states and transitions, independent of platform, styling, or branding. {% endhint %} --- ## Objectives - Model software user interfaces as a machine-readable graph. - Make procedural knowledge (“how to do X in this tool”) accessible as data, not buried in tutorials. - Provide a stable reference layer for agents and tools that need to act inside existing software. - Support both **automated** and **human-guided** mapping of real applications. - Remain platform-agnostic: web, desktop, mobile, and other environments. --- ## Components Ariane is conceptually divided into two main components. ### Theseus (Exploration Engine) Theseus is the exploratory engine that inspects real software and extracts a graph of: - **States** — distinct UI configurations (screens, dialogs, menus, etc.). - **Transitions** — user actions that move from one state to another (clicks, key presses, menu selections, etc.). It operates through platform-specific drivers (for web, desktop, mobile, etc.) that normalize different accessibility and UI APIs into a common internal representation. Theseus supports: - **Automated exploration** where interfaces are accessible and safe to probe. - **Human-guided recording** where a human operator performs actions and Theseus records the resulting states and transitions as data. See: - [Theseus](Theseus/Theseus.md) - [Theseus: Drivers](Theseus/Theseus-Drivers.md) - [Theseus: State Identification](Theseus/Theseus-State-Identification.md) - [Theseus: Exploration Engine](Theseus/Theseus-Exploration-Engine.md) - [Hybrid Mapping and Human-Guided Assistants](Consumers/Hybrid-Mapping-and-Human-Guided-Assistants.md) ### Atlas (UI Graph and Ontology) Atlas is the storage and semantic layer that persists the UI graph produced by Theseus. It provides: - A **graph model** (states and transitions). - A **core schema** for representing UI elements, actions, and app metadata. - An **ontology vocabulary** for common UI patterns and semantic intents (“Save”, “Export”, “Create”, etc.). - Metadata fields to track provenance and quality, e.g.: - `source: "auto" | "human"` - `review_status: "pending" | "verified"` External systems query Atlas to understand what actions are possible from a given state and which sequences achieve a given intent. See: - [Atlas](Atlas/Atlas.md) - [Atlas: Graph Model](Atlas/Atlas-Graph-Model.md) - [Atlas: Core Schema](Atlas/Atlas-Core-Schema.md) - [Atlas: Ontology Vocabulary](Atlas/Atlas-Ontology-Vocabulary.md) --- ## Intended Consumers Ariane is designed as a data source. Typical consumers include: - **AI agents** that need to plan and execute steps inside existing software. - **Automation tools** that want a declarative description of UI workflows. - **Analysis tools** that reason about UI complexity, accessibility, or consistency. - **Human assistants / operator consoles** that provide step-by-step textual guidance to users or operators, using Atlas as the underlying reference graph. - See: [Hybrid Mapping and Human-Guided Assistants](Consumers/Hybrid-Mapping-and-Human-Guided-Assistants.md) A future, optional overlay-style client could be built on top of Ariane as one specific consumer, but it is not part of the core scope. See: - [Consumers](Consumers/Consumers.md) - [Consumers: AI Agent Integration](Consumers/Consumers-AI-Agent-Integration.md) - [Consumers: Future Overlay Client](Consumers/Consumers-Future-Overlay-Client.md) --- ## Conceptual Flow 1. **Exploration** Theseus runs against a target application, observing the UI and exploring possible actions (either automatically, or with a human performing the actions). 2. **Extraction** It identifies UI states, fingerprints them, and records transitions between them, annotating metadata such as source (`auto` / `human`) and optional intents. 3. **Storage** The resulting graph (states + transitions + semantics) is written into Atlas using the defined schema and ontology. 4. **Consumption** External systems query Atlas to: - Recognize where a user currently is (state identification). - Determine valid next actions (outgoing transitions). - Compute paths from a current state to a goal state (intent). - Generate step-by-step guidance for human operators. --- ## Navigation - [Background: UI as Data](Concepts/Background-UI-as-Data.md) — context and motivation (“procedural knowledge gap”). - [Theseus](Theseus/Theseus.md) — exploration engine architecture and behavior. - [Atlas](Atlas/Atlas.md) — UI graph model and semantic schema. - [Hybrid Mapping and Human-Guided Assistants](Consumers/Hybrid-Mapping-and-Human-Guided-Assistants.md) — hybrid exploration and human-in-the-loop patterns. - [Consumers](Consumers/Consumers.md) — how external systems use Ariane’s data. - [Glossary](Concepts/Glossary.md) — definitions of key terms. ================================================================================================ FILE: Rejean-en/Ariane/Theseus/Theseus-Drivers.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 4a137d6dfea6c4c1035ce681aebd09c89580d7310335adace1e8dcc1d8180969 CONTENT_BYTES: 1734 ================================================================================================ # Theseus / Drivers Drivers are the platform-specific adapters that allow Theseus to explore real software. Each driver connects to a particular UI technology (web, desktop, mobile, etc.) and exposes a normalized view of the interface to the Theseus core: - A tree of UI elements (roles, labels, hierarchy). - A way to identify which elements are interactive. - A way to perform abstract actions (activate, set value, focus, etc.). The goal is that the core logic never needs to know whether it is exploring a browser, a native desktop app, or a mobile app. --- ## Driver Responsibilities Every driver is responsible for: 1. **Tree acquisition** - Retrieve the current UI/accessibility tree. - Provide a stable, hierarchical representation (nodes, children, attributes). 2. **Element characterization** - Mark which elements are interactive (buttons, links, inputs, menu items, etc.). - Expose roles, labels, and metadata (e.g., enabled/disabled, checked/unchecked). 3. **Action execution** - Provide operations such as: - `activate(elementId)` – click or trigger an action. - `setValue(elementId, value)` – enter text, toggle a checkbox, select an option. - `focus(elementId)` – move focus to an element. 4. **Context metadata** - Report app identifier, version, platform, locale, and any other relevant context. 5. **Error handling** - Report failures (e.g., element vanished, access denied) in a way the core can interpret. --- ## Driver Model Conceptually, Each driver implements an interface like: ```text Driver: getTree() -> UITree listInteractiveElements(tree) -> [UIElement] perform(action: AbstractAction) -> Result getContext() -> ContextMetadata ================================================================================================ FILE: Rejean-en/Ariane/Theseus/Theseus-Exploration-Engine.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 8cae321442f58e3c7a63bef13fc0654e84be4812f12fbafb81d50cafe35ed3e2 CONTENT_BYTES: 7019 ================================================================================================ # Theseus / Exploration Engine The Exploration Engine controls how Theseus moves through an application: - Which elements to interact with. - In what order to explore them. - When to stop. - How to avoid unsafe or unproductive actions. Its goal is to build a useful UI graph with bounded effort, while minimizing risk. --- ## Inputs and Outputs **Inputs:** - Current **state** (UI tree + state ID). - List of **interactive elements** for that state. - Exploration configuration: - Depth limits. - Action filters. - Safety constraints. **Outputs:** - A sequence of **actions** taken. - Newly discovered **states** and **transitions**. - Metadata about exploration coverage (visited states, pruned paths, errors). --- ## Core Loop Conceptually, the Exploration Engine runs a loop like this: 1. Identify the current state (using state identification). 2. If the state is new: - Record it. - Enumerate candidate actions. 3. Pick a safe, unexplored action. 4. Execute the action via the driver. 5. Observe the resulting UI and compute the next state. 6. Record a transition from the previous state to the new state. 7. Repeat until no further actions are available within constraints. --- ## Traversal Strategy The engine treats the UI as an implicit graph it is progressively revealing. ### Depth-First Exploration A simple and useful default is **depth-first search (DFS)**: - Choose an unexplored action from the current state. - Follow it until: - A new state is discovered, or - A known state is reached (loop). - Backtrack when: - All actions from a state have been explored or pruned. - Depth limits are reached. Benefits: - Easy to implement. - Naturally builds complete *paths* (useful for downstream consumers). Other traversal modes (e.g., breadth-first, heuristic-guided search) can be added, but DFS is a good baseline. --- ## Loop Detection and State History To avoid infinite loops and redundant work: - The engine keeps a **visited set** of state IDs. - Each state has a record of: - Which actions have already been taken. - Which outgoing transitions have been observed. If an action leads to a state that is already known: - A new **edge** (transition) is recorded. - The engine may still explore alternate actions from the current state, but it avoids revisiting the same transition repeatedly. This ensures the exploration converges even if the application allows cycling between screens. --- ## Action Selection and Prioritization Not all actions are equally important. The engine can prioritize: - **Top-level navigation** (menus, tabs, primary buttons). - **Dialogs and modals** (things that lead to new interaction surfaces). - **Configuration sections** (tabs/panels inside settings). - **Highly visible controls** (buttons in prominent positions). Examples of filters: - Ignore elements that: - Are off-screen or not visible. - Are known to be irrelevant (e.g., specific controls in debugging overlays, when detectable). - Deprioritize: - Elements that appear identical or near-duplicate within the same region. - Controls that seem purely decorative. Exact heuristics can be tuned per application or platform. --- ## Safety and Risk Management Some actions are potentially destructive (e.g., delete, reset, format, uninstall). The engine should avoid them by default unless running in a controlled sandbox. Safety mechanisms include: - **Keyword-based filters** - Skip actions whose labels or descriptions match high-risk patterns (e.g., “Delete”, “Erase”, “Format”, “Reset”, “Uninstall”), especially when combined with red styling or warning icons. - **Scope constraints** - Do not navigate into obviously hazardous subsystems (e.g., system-level disk tools) unless explicitly allowed. - **Confirmation detection** - If an action opens a destructive confirmation dialog, treat this as a discovered state without proceeding further. - **Configurable risk profiles** - Allow running in: - “Safe mode” – conservative, avoids any destructive-looking action. - “Sandbox mode” – more permissive, for controlled environments such as test VMs. The Exploration Engine should treat safety as a first-class concern. --- ## Handling Non-Standard UIs Some UIs do not expose sufficient accessibility information to support tree-based exploration. In these cases, the engine may enable **fallback modes** via the driver: 1. **Vision-based candidate detection** - Capture a screenshot. - Detect potential interactive regions (buttons, inputs, menus) using vision heuristics. - Use OCR to infer text labels where possible. 2. **Coordinate-based interaction** - Treat candidate regions as elements. - Perform actions by clicking/tapping at their coordinates. Trade-offs: - Less reliable than accessibility-based exploration. - Harder to map precisely back into structured UI trees. - Best used for narrow, targeted exploration in controlled conditions. --- ## Exploration Limits To keep exploration tractable, the engine uses explicit limits: - **Depth limit** - Maximum length of a path from the starting state. - **State limit** - Maximum number of distinct states to discover in a single run. - **Action limit per state** - Maximum number of actions to attempt from any given state. When a limit is reached, the engine: - Stops further exploration. - Outputs the partial graph discovered so far. These limits can be configured depending on: - Target application complexity. - Time/resources available. - Desired coverage. --- ## Error Handling and Recovery During exploration, actions can fail in various ways: - Element disappears before activation. - App becomes unresponsive. - OS denies access to certain windows. The engine should: - Record errors as annotations on transitions or states. - Attempt to recover by: - Returning to a known stable state (e.g., main window). - Restarting the application if necessary (under driver control). - Avoid infinite retry loops. Failures are data too: they indicate unreachable paths or restricted states. --- ## Output for Atlas The Exploration Engine provides Atlas with: - **States** - IDs, fingerprints, and interactive elements. - **Transitions** - Source state, target state, action metadata, and any semantic hints. - **Coverage metadata** - Which states were fully explored, partially explored, or unreachable. - Any errors or safety-related skips. Atlas then persists this information and makes it available to consumers. --- ## Related Pages - [Theseus](Theseus.md) – overview of the exploration engine. - [Theseus/State-Identification](Theseus-State-Identification.md) – how states are fingerprinted and recognized. - [Atlas](Atlas.md) – how the discovered graph is stored and exposed to external systems. - [Consumers/AI-Agent-Integration](Consumers-AI-Agent-Integration.md) – how agents use the resulting graph during guidance. ================================================================================================ FILE: Rejean-en/Ariane/Theseus/Theseus-State-Identification.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: e0f60afd594d11ce206d74401aa02c8f1845d7052d6211ded960ce5ca2546492 CONTENT_BYTES: 2587 ================================================================================================ # Theseus / State Identification State identification is how Theseus decides whether the current UI is: - A **new state** it has never seen before, or - A **known state** it has already mapped. To build a stable UI graph, Theseus needs state identifiers that: - Are stable under small cosmetic changes. - Change when the structure or functionality meaningfully changes. - Can be computed across different platforms and drivers. --- ## What Is a State? For Ariane, a **state** is: > A specific configuration of the user interface that is relevant for interaction and navigation. Examples: - Main window of an application. - A dialog (e.g., “Save as”, “Preferences”). - A subview or screen (e.g., “Export”, “Settings”, “New project”). A state is represented by: - The structure of the UI tree. - The set and arrangement of interactive elements. - Optionally, an associated screenshot or visual representation. --- ## Fingerprints Each observed UI tree is converted into a **fingerprint**. Fingerprints are used to derive: - A **state ID** – a compact identifier used in the graph. - A notion of **similarity** – to decide whether two observations represent the same state or a variant. A typical fingerprint is composed of: 1. **Structural hash** - Encodes the shape and roles of the UI tree: - Node types (button, input, menu item, etc.). - Hierarchical relationships. - Insensitive to purely visual changes (e.g., colors, fonts). 2. **Visual hash (perceptual)** - Encodes the appearance of the screen (e.g., pHash of a screenshot). - Robust to small visual differences but changes when layout/content changes visibly. 3. **Optional semantic hash** - Encodes textual content (labels, titles) using OCR or accessibility text. - Useful when structure is similar but text differences matter. --- ## Example: Fingerprint Computation (Conceptual) Pseudo-code, omitting implementation details: ```python def compute_fingerprint(ui_tree, screenshot=None, text_tokens=None): structure_id = hash_tree_structure(ui_tree) visual_id = perceptual_hash(screenshot) if screenshot is not None else None semantic_id = hash_text_tokens(text_tokens) if text_tokens is not None else None return { "structure": structure_id, "visual": visual_id, "semantic": semantic_id, } def compute_state_id(fingerprint): parts = [ fingerprint["structure"], fingerprint.get("visual") or "", fingerprint.get("semantic") or "", ] return hash_concatenate(parts) ================================================================================================ FILE: Rejean-en/Ariane/Theseus/Theseus.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: bc5f4934ead3d87aa3cc57cd113b6ba25d696788a9ae77ad9f7c24fded068ec3 CONTENT_BYTES: 1871 ================================================================================================ # Theseus Theseus is Ariane’s exploration engine. It inspects real software, discovers which UI states exist, and records how user actions move between them. The result is a graph of states and transitions suitable for storage in Atlas and consumption by external systems. Theseus itself does not make decisions for users. Its job is to observe, explore, and describe. --- ## Responsibilities Theseus is responsible for: - **State discovery** Detecting distinct UI configurations (screens, dialogs, menus, etc.). - **Transition discovery** Observing how user actions (clicks, keypresses, gestures) move the UI from one state to another. - **State identification** Assigning stable identifiers to states, so they can be recognized again even if minor visual details change. - **Graph construction** Emitting a consistent set of nodes (states) and edges (transitions) that can be stored in Atlas. --- ## High-Level Architecture Theseus is structured around a clear separation between platform-agnostic logic and platform-specific drivers. ```text +---------------------------------------------------------------+ | THESEUS CORE | | | | [State Manager] <--> [Exploration Engine] <--> [Output] | +----------------------------^----------------------------------+ | +-------+--------+ | Abstraction | | Layer | +-------+--------+ | +----------------------+------------------------+ | | | [Web Driver] [Desktop Driver] [Mobile Driver] (browser, DOM) (UIA/AT-SPI, etc.) (accessibility APIs) ================================================================================================ FILE: Rejean-en/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: f2f9a750d4ba6609acc6fb9664cf0d0cd786ac251389799636ce39cc8da3c8a3 CONTENT_BYTES: 6222 ================================================================================================ # Réjean McCormick ### Socio-technical Architect I design and ship civic utilities: shared infrastructure that helps people learn, coordinate, and govern together. My work bridges rigid technical systems with fluid narrative layers. I build engines that deconstruct linear human language into structured, universal concepts—enabling organizations to be faster, smarter, and independent. **Academic Profile:** [PhilPeople/Rejean-McCormick](https://philpeople.org/profiles/rejean-mccormick) --- ## The Strategy: Connection vs. Independence My architecture is built on a deliberate balance between two opposing needs: 1. **Global Connection (Konnaxion):** A public ecosystem to connect everyone and share knowledge openly. 2. **Hermetic Independence (Orgo):** A private, closed-network nervous system for organizations that need absolute data sovereignty. To achieve this without relying on external "Big Tech" APIs or constant internet access, I had to build my own engines. --- ## The Engines (Core Logic) These are the active processors that power the ecosystem. ### SenTient: The Deconstructor **Status:** *Active Development (Open Source)* **Technical Classification:** NLP Engine (Entity Reconciliation & Relation Extraction) To make Orgo and Konnaxion truly independent, I needed a "language deconstructor" that could operate offline, without relying on external LLMs. * **The Build:** I merged the best features of **OpenTapioca**, **Falcon**, and **OpenRefine** into a single, streamlined tool. * **The Function:** It deconstructs linear human sentences and maps them into structured Wikidata items (concepts). This process not only secures the entry point but allows information to flow more effectively through internal ducts by removing ambiguity. * **The Goal:** Enable language-independent data flow within private bubbles (Orgo) or public networks (Konnaxion). * [Access *SenTient* Technical Wiki](SenTient/SenTient-Engine-Hub.md) ### Abstract Wiki Architect **Status:** *Active Development (Open Source)* **Technical Classification:** NLG Middleware (Natural Language Generation) To make Konnaxion available to all, I needed a way to generate multilingual articles from abstract data. Since no existing solution was ready, I initiated building this architect. * **Role:** Structural design and relationship mapping for the wiki ecosystem. * **[Wikimedia Tool Page](https://meta.wikimedia.org/w/index.php?title=Abstract_Wikipedia/Tools/abstract-wiki-architect)** * [Access *Architect* Technical Wiki](abstract-wiki-architect/Wiki-Architect-Hub.md) --- ## The Ecosystem: KOA **KOA** is the public-good ecosystem built on top of these engines. ### 1. Konnaxion (The Open Web) **Technical Classification:** Multi-Tenant Web Platform (Social-Civic) * **Mission:** Connect everyone. Stitches together existing OER catalogs and civic tools rather than rebuilding them. * **Modules:** KonnectED (Education), keenKonnect (R&D), Ethikos (Governance), Kreative (Culture). * **[Official Site (konnaxion.com)](https://konnaxion.com)** * **[Presentation of Konnaxion (formerly "Knowledge Hub") (kingklown.wiki)](https://kingklown.wiki/)** * [Access *Konnaxion* Technical Wiki](Konnaxion/Konnaxion-Hub.md) ### 2. Orgo (The Hermetic Bubble) **Technical Classification:** Private Enterprise SaaS / ERP Platform * **Mission:** Organize and Go. A multi-tenant nervous system for organizations (gov, business, schools). * **Independence:** Designed to operate in a "bubble" (closed network) for three critical reasons: 1. **Privacy:** Can run completely disconnected from any network, ensuring zero data leakage. 2. **Resilience:** Functions autonomously even if the global internet goes down. 3. **Security:** Minimizes entry points. All inputs must pass through **SenTient**, which deconstructs the language into safe, structured data before it ever touches the internal system. * **[Presentation of Orgo](https://administrative-efficienc-0u6vhrh.gamma.site/)** * [Access *Orgo* Technical Wiki](Orgo/Orgo-System-Hub.md) --- ## Commercial & Research Modules Specific architectural components that handle intelligence and navigation. ### Ariane (Commercial) **Status:** *For Sale / Commercial Licensing* **Technical Classification:** Semantic Middleware / Knowledge Graph Infrastructure The "Thread" and navigation system. Ariane handles graph models and ontology vocabularies (Atlas) to guide users through complex data structures. * [Access *Ariane* Technical Wiki](Ariane/Ariane-Hub.md) ### SwarmCraft **Status:** *Research / Open Source* **Technical Classification:** Deterministic Workflow Engine Managing swarm intelligence and prompt engineering pipelines. Focuses on deterministic execution and slice-by-slice orchestration. * [Access *SwarmCraft* Technical Wiki](SwarmCraft/SwarmCraft-Hub.md) ### Ame-Artificielle (Artificial Soul) **Status:** *Research / Open Source* **Technical Classification:** AI Alignment & Meta-Cognition Framework Concepts of AI alignment and meta-cognition. Defines ethics, governance, and functional specifications for synthetic souls. * [Access *Âme Artificielle* Technical Wiki](Ame-Artificielle/Ame-Vision-Hub.md) --- ## The Narrative Layer To make these systemic ideas legible and engaging, I utilize a narrative engine around **King Klown** and **Surreal**. * **Fiction Cycles:** *King Klown Kronicles* ([Amazon](https://www.amazon.ca/stores/R%C3%A9jean-McCormick/author/B0G3B7DQWG?ref=ap_rdr&shoppingPortalEnabled=true)). * **Media:** Podcasts, audiobooks, and soundscapes ([Spotify](https://open.spotify.com/show/2hMamhJENVfWsULSuUVEG4)). * **Stage Work:** *Le Ninja Arc-en-ciel* ([Watch on YouTube](https://www.youtube.com/watch?v=Cz7qhJNDzuo) | [Listen on SoundCloud](https://soundcloud.com/rejean-mccormick/sets/ninja_arc-en-ciel)). --- ## Hubs & Connectors * **Source Code:** [GitHub/Rejean-McCormick](https://github.com/Rejean-McCormick) ### Social Channels * **Facebook:** [Profile](https://www.facebook.com/profile.php?id=61559861434513) * **X (Twitter):** [@KingKlownXYZ](https://x.com/KingKlownXYZ) * **Mastodon:** [@Rejean_McCormick](https://mastodon.social/@Rejean_McCormick) ================================================================================================ FILE: Rejean-en/Konnaxion/Ethikos/Konsultations.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ebb0219cb85e6e9dbe566b32239be0df3ef104b75971c7317d621c4811ab2f36 CONTENT_BYTES: 4664 ================================================================================================ **Konsultations (Public Consultations & Feedback)** — sub‑module under **ethiKos**. Implements five core services with stable code‑names, backed by consultation/suggestion/vote/result/impact models and frozen routing/analytics invariants. --- ### **1\) Functional Services (and expected files)** Code‑names map 1:1 to Django service modules; file names follow the `services/.py` convention. | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Public Consultations | `public_consultation` | Create and run time‑boxed civic consultations (setup, schedule, close). | `services/public_consultation.py` | | Citizen Suggestions | `citizen_suggestion` | Intake pipeline for user‑proposed ideas/amendments feeding into consultations. | `services/citizen_suggestion.py` | | Weighted Voting (EkoH) | `weighted_consultation_vote` | Cast ballots with optional EkoH‑based weighting; aggregates to results. | `services/weighted_consultation_vote.py` | | Results Visualization | `consultation_result_visualization` | Compute/serve KPIs and breakdowns for dashboards. | `services/consultation_result_visualization.py` | | Impact Tracking | `impact_tracking` | Log follow‑up actions and implementation status for adopted proposals. | `services/impact_tracking.py` | --- ### **2\) Backend functionalities** * **Consultation lifecycle.** CRUD for consultations with scheduling (open/close) and status transitions; business rules on who can launch/manage, exposed via DRF. * **Suggestion intake → consultation.** Users submit suggestions; moderators/owners triage and link them to an active consultation or backlog for future cycles. * **Ballots with weighting.** Store raw and EkoH‑weighted ballot values per user/consultation; recompute totals on each vote/change; optional live push via Channels/Redis. * **Results & dashboards.** Persist snapshot JSONs for totals/segments; serve aggregates to the UI and to the analytics pipeline. * **Impact follow‑through.** Record action items that implement approved proposals; status progression and audit trail. --- ### **3\) Database models (OLTP)** Actual tables implemented for Konsultations. | Table / Model | Purpose | Key fields | | ----- | ----- | ----- | | `Consultation` | A consultation instance (time‑boxed). | `id`, `title`, `open_date`, `close_date`, `status` (ENUM) | | `CitizenSuggestion` | User‑submitted ideas tied to a consultation. | `id`, `consultation` (FK), `author` (FK), `content` | | `ConsultationVote` | Ballots with raw and EkoH‑weighted values. | `id`, `user` (FK), `consultation` (FK), `raw_value`, `weighted_value` | | `ConsultationResult` | Aggregated outcomes (snapshot). | `id`, `consultation` (FK), `results_data` (JSONB) | | `ImpactTrack` | Post‑consultation action log. | `id`, `consultation` (FK), `action`, `status`, `date` | --- ### **4\) Supporting configuration (frozen)** * **Ballot modalities** (available to consultations via Smart Vote): `approval`, `ranking`, `rating`, `preferential`. * **Smart‑Vote thresholds** (used when labeling outcomes, platform‑wide): e.g., `CONSENSUS_STRONG_THRESHOLD ≥ 75%` weighted agreement. * **Route invariants:** `/consult` namespace is owned by **ethiKos** (no other module may claim it). --- ### **5\) Routes & ownership** * **Primary UI:** `/consult` (**Consultation Hub**) with tabs **Live / Results / Suggest**. * **Analytics:** `/ethikos/insights` for opinion analytics related to debates/consultations (read‑only). --- ### **6\) Integration points** * **EkoH weighting & Smart Vote.** Consultation ballots can use the same reputation‑weighted engine as debates; results reflect domain expertise where configured. * **Insights (ETL \+ dashboards).** Voting events flow to the analytics star schema via `etl_smart_vote` (every 10 min) and power `/reports/smart-vote`. --- ### **7\) Realtime & ops** * **Live updates:** Optional push of result deltas via Django Channels \+ Redis. * **Caching:** Use Redis to cache popular result filters/segments to reduce recomputation. --- **Summary** Konsultations provides time‑boxed consultations, suggestion intake, EkoH‑weighted ballots, and transparent result snapshots through five services (`public_consultation`, `citizen_suggestion`, `weighted_consultation_vote`, `consultation_result_visualization`, `impact_tracking`). Data persists in `Consultation`, `CitizenSuggestion`, `ConsultationVote`, `ConsultationResult`, and `ImpactTrack`; routing is fixed at `/consult`, and analytics integrate with the platform’s Smart‑Vote ETL and dashboards. ================================================================================================ FILE: Rejean-en/Konnaxion/Ethikos/Korum.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 61ae3dc9ba9a84a0b0334fb7ea4255af53c59c1c628134fca037cdfaaa573417 CONTENT_BYTES: 4503 ================================================================================================ **Korum (Structured Debates)** — sub‑module under **ethiKos**. Implements five core services with defined code‑names, backed by concrete debate/stance/argument models and fixed parameters. --- ### **1\) Functional Services (and expected files)** Each service name is stable and maps to a dedicated Django service module (file paths reflect the cookiecutter layout; exact filenames may vary by repo). | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Structured Debates | `structured_debate` | Create and manage ordered debate sequences and topics. | `ethikos/services/structured_debate.py` | | Klônes IA | `ai_clone_management` | Manage AI expert‑emulating agents for continuity/testing. | `ethikos/services/ai_clone_management.py` | | Comparative Analysis | `comparative_argument_analysis` | Compare arguments to surface convergences/divergences. | `ethikos/services/comparative_argument_analysis.py` | | Public Archiving | `public_debate_archive` | Produce immutable debate snapshots for transparency. | `ethikos/services/public_debate_archive.py` | | Automated Summaries | `automated_debate_summary` | Generate concise, structured debate outcome digests. | `ethikos/services/automated_debate_summary.py` | --- ### **2\) Backend functionalities** * **Debate lifecycle:** CRUD for topics with status transitions (open/closed/archived), category assignment, and owner/moderation rules; exposed via DRF. * **Threaded arguments:** Nested replies under each topic with optional “pro/con” flag and moderation hooks. * **Nuanced stance capture:** Integer stance scale −3…+3 per user/topic; integrates with Smart Vote for weighted aggregation. * **Weighted results & cohorts:** Results recomputed by expertise cohorts (EkoH) and other filters; realtime push optional via Channels/Redis. * **Quality & moderation:** Report/auto‑hide thresholds; flagged content routed to shared moderation queue. --- ### **3\) Database models (OLTP)** Actual implemented tables for Korum (planned AI/summary/archive tables are intentionally omitted in v14). | Table / Model | Purpose | Key fields | | ----- | ----- | ----- | | `EthikosCategory` | Thematic categories for debates. | `id`, `name`, `description` | | `EthikosTopic` | Debate topic/question. | `id`, `title`, `status`, `start_date`, `end_date` | | `EthikosStance` | User stance on a topic (−3…+3). | `id`, `topic` (FK), `user` (FK), `value` | | `EthikosArgument` | User argument/post (threaded). | `id`, `topic` (FK), `author` (FK), `content`, `parent` (FK), `side` (enum, optional) | Note: AI clones, comparative‑analysis logs, public archives, and debate summaries are listed as services but not present as tables in the current schema snapshot. --- ### **4\) Supporting configuration (frozen)** * **Stance scale:** −3 … \+3 (0 \= neutral). * **Expert cohort quorum (display):** 12 distinct experts (Ekoh threshold per domain). * **Moderation auto‑hide:** Hide an argument after 3 independent reports. * **AI clone training batch:** 128 records. --- ### **5\) Frontend & navigation** * **Routes:** `/debate` (Debate Hub: Open / Archived / Start New), `/ethikos/insights` (opinion analytics dashboards). * **Behavior:** Stance slider (−3…+3), live tallies, cohort filters, threaded arguments; analytics readouts live under Insights. --- ### **6\) Integration points** * **EkoH & Smart Vote:** Stances are aggregated using EkoH reputation to compute weighted results; outcomes can feed analytics (/reports/smart‑vote). * **Insights module:** ETL ingests vote/stance facts; dashboards render trends with export limits and privacy safeguards (k‑anonymity, hashed IDs). --- ### **7\) Realtime & ops** * **Push updates:** Optional WebSocket broadcasts via Django Channels \+ Redis for stance/result changes. * **Caching & rate control:** Use Redis caching for common cohort filters; apply API throttles consistent with platform policy. --- ### **Summary** Korum provides structured topic management, nuanced stance capture, and threaded argumentation, with weighted consensus via EkoH/Smart Vote. Its five named services are stable integration points; the production schema covers categories, topics, stances, and arguments, while advanced AI/archive features run as services without additional OLTP tables in v14. Routes and parameters are version‑locked to ensure predictable behavior across UI, API, and analytics. ================================================================================================ FILE: Rejean-en/Konnaxion/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 8bef5bf0231d40d9a10d615001b226aec8c8220558753c848aec32757e675a43 CONTENT_BYTES: 4655 ================================================================================================ # Konnaxion – Civic Workflows & Module Interactions Konnaxion is a socio‑technical framework for coordinating people, knowledge, and action through an ethical, modular civic architecture built on the KOA model: **KonnectED, Ethikos, Kreative, keenKonnect, EkoH, Smart Vote**. This page is the **hub** for the wiki. It summarizes how modules relate to each other, and it links to detailed pages for each sub‑module. For implementation details (models, services, parameters), use the dedicated technical page linked at the end. [Visit the Dashboard](https://konnaxion.com/ekoh/dashboard) [For an illustrated presentation of the purpose of Konnaxion, the "Knowledge Plateform".](https://kingklown.wiki/) --- ## Wiki structure Overall structure: * **Konnaxion – Civic Workflows & Module Interactions** *(this page)* ### KonnectED * [Knowledge](KonnectED/Knowledge.md) — Collaborative Learning Library: catalog, recommendations, co‑creation, forums, progress tracking. * [CertifiKation](KonnectED/CertifiKation.md) — Skills & Certification: paths, evaluations, peer validation, portfolios, credentials. ### Ethikos * [Korum](Ethikos/Korum.md) — Structured Debates: topics, −3…+3 stances, threaded arguments, expert cohorts, summaries. * [Konsultations](Ethikos/Konsultations.md) — Public Consultations & Feedback: time‑boxed consultations, citizen suggestions, weighted ballots, impact tracking. ### Kreative * [Konservation](Kreative/Konservation.md) — Creative Content & Cultural Preservation: digital archives, virtual exhibitions, AI‑enriched catalog, partner collections. * [Kontact](Kreative/Kontact.md) — Collaboration & Networking: profiles, intelligent matching, collaboration rooms, opportunities, endorsements. ### keenKonnect * [Konstruct](keenKonnect/Konstruct.md) — Project Collaboration Spaces: project workspaces, tasks, chat, AI insights, project ratings. * [Stockage](keenKonnect/Stockage.md) — Secure Repository & Versioned Storage: document/blueprint storage, versioning, indexing, real‑time sync. ### Kollective Intelligence * [EkoH](Kollective-Intelligence/EkoH.md) — Reputation & Expertise: multidimensional scoring, ethical multipliers, privacy controls, audit trails. * [Smart Vote](Kollective-Intelligence/Smart-Vote.md) — Weighted Voting System: EkoH‑weighted voting, multiple modalities, emerging‑expert detection, analytics. Use this section as the navigation menu for the wiki: start from the KOA area you care about, then dive into its sub‑module page for details. --- ## Civic workflow at a glance The README outlines a civic workflow “proposal → deliberation → decision → action.” The KOA modules map onto that pipeline as follows: 1. **Learn & build competence – KonnectED** People explore resources and courses in **[Knowledge](KonnectED/Knowledge.md)**, then earn certifications through **[CertifiKation](KonnectED/CertifiKation.md)**, building skills and portfolios. 2. **Deliberate & consult – Ethikos** Complex issues are debated in **[Korum](Ethikos/Korum.md)** with nuanced stances and arguments, while broader participation is organized via **[Konsultations](Ethikos/Konsultations.md)** for structured public input. 3. **Weigh & decide – Kollective Intelligence** **[EkoH](Kollective-Intelligence/EkoH.md)** computes domain‑specific reputation and ethics scores; **[Smart Vote](Kollective-Intelligence/Smart-Vote.md)** uses them to weight ballots and stances, exposing both raw and weighted outcomes. 4. **Execute & coordinate – keenKonnect** Adopted proposals become projects in **[Konstruct](keenKonnect/Konstruct.md)**, with tasks, chat, and AI summaries, while **[Stockage](keenKonnect/Stockage.md)** manages all related documents and blueprints. 5. **Preserve & connect – Kreative** Outputs are archived and exhibited through **[Konservation](Kreative/Konservation.md)**, and relationships and opportunities are managed via **[Kontact](Kreative/Kontact.md)**, feeding back into future cycles of work. --- ## Technical architecture and services For details about: * service code‑names and how they map to Django modules * core models and configuration parameters (thresholds, limits, routes) * real‑time infrastructure (Channels/Redis), ETL jobs, and analytics flows see the dedicated technical page: * [Konnaxion – Technical Architecture & Services](Technical/Konnaxion-Technical-Architecture-And-Services.md) That page consolidates the “technicalities” from the module specifications and the original system‑overview draft, so this hub can stay focused on workflows and navigation. ================================================================================================ FILE: Rejean-en/Konnaxion/keenKonnect/Konstruct.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ceb6e1e452c27bf61b9fe8a4a77431aabef8eafc1ae96cf46174e938e32cda63 CONTENT_BYTES: 5401 ================================================================================================ **Konstruct (Project Collaboration Spaces)** — first sub‑module under **keenKonnect**. Implements five core services with concrete code‑names, backed by project/task/chat models and fixed parameters. --- ### **1\) Functional Services (and expected files)** | Display name | Code name / service | Purpose / behavior | Likely file or module | Status | | ----- | ----- | ----- | ----- | ----- | | Virtual Collaboration Spaces | `collaboration_space` | Create/join project rooms with membership, roles, and access rules. | `keenkonnect/services/collaboration_space.py` | Implemented (projects & teams) | | Project Management Tools | `project_task_management` | Tasks, Kanban states, assignees, due dates, and activity logs. | `keenkonnect/services/project_task_management.py` | Implemented (tasks) | | Real‑Time Editing | `real_time_document_editing` | Synchronous co‑editing of docs; conflict resolution (OT/CRDT pattern). | `keenkonnect/services/real_time_document_editing.py` | Planned (MVP uses resource versioning) | | Integrated Chat & Video | `integrated_communication` | Per‑project chat via sockets; optional video sessions via provider. | `keenkonnect/services/integrated_communication.py` | Chat implemented; video wired by env | | AI Collaborative Analysis | `ai_collaboration_analysis` | Live summaries, action suggestions, and collaborator recommendations. | `keenkonnect/services/ai_collaboration_analysis.py` | Implemented (summaries/reco service) | Code‑names and scope are defined in the v14 service inventory. --- ### **2\) Backend Functionalities** * **Project lifecycle & membership.** Create/update/archive projects; manage membership and roles; enforce access on project‑scoped endpoints. * **Tasking.** CRUD tasks with statuses (todo/in‑progress/done/blocked), assignment, due dates, ordering; emits project activity events. * **Resources & blueprints.** Attach documents and 3D assets; optional background conversion/previews for CAD/3D models (e.g., glTF) via worker jobs. * **Collaboration channels.** Real‑time project chat over WebSockets; optional video sessions bound by provider config; rate‑limits and moderation hooks applied. * **Real‑time document editing (MVP).** Until dedicated models land, uses resource versioning plus optimistic locking; planned upgrade to true real‑time persistence. * **AI assistance.** Generate meeting notes, decisions, and next‑actions from chat/tasks; recommend collaborators based on skills/Ekoh domains. --- ### **3\) Database Models (OLTP)** Actual models present in the codebase for Konstruct‑level collaboration; names/purposes below. | Table / Model | Purpose | Key fields (abridged) | | ----- | ----- | ----- | | `Project` | Project workspace container. | `id`, `title`, `description`, `creator`, `category`, `status` | | `ProjectResource` | Files/links attached to a project (incl. blueprints). | `id`, `project`, `title`, `url`, `added_by` | | `ProjectTask` | Tasks/milestones for the project. | `id`, `project`, `title`, `description`, `assignee`, `status`, `due_date` | | `ProjectMessage` | Project chat/message history. | `id`, `project`, `sender`, `content` | | `ProjectTeam` | Membership and roles. | `id`, `project`, `user`, `role`, `joined_at` | | `ProjectRating` | Community validation signal. | `id`, `project`, `user`, `rating`, `comment` | | `Tag` | Reusable keyword taxonomy. | `id`, `name` | **Not present (planned names suggested by docs):** `RealTimeDocument`, `DocumentRevision`, `VideoSession`, `AIInteractionLog`. The schema note explicitly calls these out as missing today. --- ### **4\) Supporting Configuration (frozen)** | Parameter | Location | Final value / notes | | ----- | ----- | ----- | | `MAX_BLUEPRINT_UPLOAD_MB` | `settings.STORAGE` | **150 MB** maximum per file | | `ALLOWED_BLUEPRINT_TYPES` | `ProjectResource` | `[".pdf", ".png", ".jpg", ".glb", ".gltf", ".stl"]` | | `COLLAB_SPACE_MEMBER_CAP` | `CollaborationSpace` | **40** members per space | | `AI_SUGGESTION_TOP_N` | `settings.KEENKONNECT` | **8** collaborator suggestions | | `VIDEO_SESSION_PROVIDER` | env `KC_VIDEO_PROVIDER` | `"livekit"` (self‑hosted) | These parameters are locked in the Global Parameter Reference. --- ### **5\) Routes & UI Surface** * **/projects** → Project Studio (Browse, Create, My Projects). * **/projects/\[slug\]** → Single Workspace with tabs: **Overview**, **Tasks**, **Blueprints**, **Chat**, **AI Insights**, **Settings**. Top‑level routing invariants assign these paths to the keenKonnect app. --- ### **6\) Runtime & real‑time** * **WebSockets:** Django Channels \+ Redis for chat/notifications; project‑scoped groups per workspace. * **File storage:** Object storage (S3/MinIO) for blueprints; optional preview/convert workers for 3D assets. * **Video:** Session bootstrap via the configured provider (`KC_VIDEO_PROVIDER`). --- ### **Summary** Konstruct exposes five services—`collaboration_space`, `project_task_management`, `real_time_document_editing`, `integrated_communication`, `ai_collaboration_analysis`—implemented over the `Project`, `ProjectTask`, `ProjectMessage`, `ProjectTeam`, `ProjectResource`, `ProjectRating`, and `Tag` models, with fixed size/type/member caps and dedicated routes under `/projects`. Real‑time editing is currently backed by resource versioning, with dedicated models planned. ================================================================================================ FILE: Rejean-en/Konnaxion/keenKonnect/Stockage.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 202621aacc3a8d0dd78e3305d922cdd0dbbf1cf30a676be6ca911bcb9c95bee3 CONTENT_BYTES: 5014 ================================================================================================ **Stockage (Secure Repository & Versioned Storage)** — second sub‑module under **keenKonnect**. Implements five services with defined code‑names, backed by project‑scoped resource models and fixed storage/search parameters. --- ### **1\) Functional Services (and expected files)** Code‑names come from the v14 services inventory; each maps to a Django service module imported by API controllers and Celery tasks. | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Secure Repository | `secure_document_storage` | Persist files with authenticated access and per‑project visibility. | `apps/keenkonnect/services/secure_storage.py` | | Automatic Versioning | `document_versioning` | Maintain sequential revisions; enable diff/rollback semantics. | `apps/keenkonnect/services/document_versioning.py` | | Intelligent Indexing | `intelligent_indexing` | Extract metadata/keywords; update full‑text search index. | `apps/keenkonnect/services/indexing.py` | | Real‑Time Sync | `real_time_sync` | Broadcast file add/update/delete to active collaborators. | `apps/keenkonnect/services/real_time_sync.py`, `apps/keenkonnect/channels/consumers.py` | | Fine‑Grained Permissions | `granular_permissions` | Enforce document‑level ACLs beyond project roles. | `apps/keenkonnect/services/permissions.py` | --- ### **2\) Backend Functionalities** * **Upload & storage pipeline.** Accept files under an explicit size/type policy; persist metadata and storage URL on the `ProjectResource` table; store blobs in the configured media bucket (S3/MinIO). * **Versioning semantics.** Expose create‑new‑revision, list revisions, restore, and compute diffs via `document_versioning`. The Database Reference documents `ProjectResource` as the current file record; dedicated version entities are not detailed there and can be added alongside this service. * **Indexing & search.** On upload/update, `intelligent_indexing` extracts text/keywords and refreshes the platform’s PostgreSQL full‑text index (SEARCH\_BACKEND=“postgres”), enabling global search and in‑workspace filtering. * **Access control.** Enforce read/write/admin by project membership (`ProjectTeam`) and, where required, per‑document ACL through `granular_permissions`. Current schema formalizes project‑level roles; document‑level ACL tables are not enumerated in the v14 schema file. * **Real‑time notifications.** `real_time_sync` uses Django Channels over Redis to push “file added/updated/removed” events to clients in `/projects/[slug]` workspaces. --- ### **3\) Database Models** Stockage persists file metadata as project resources; project membership governs default access. | Table / Model | Purpose | Key fields (abridged) | | ----- | ----- | ----- | | `ProjectResource` | Link a document/file (blueprint, image, 3D model, guide) to a project. | `id`, `project`, `title`, `url`, `added_by`, timestamps | | `Project` | Workspace container for resources and collaboration. | `id`, `title`, `description`, `creator`, `category`, `status` | | `ProjectTeam` | Membership & role for access control. | `id`, `project`, `user`, `role`, `joined_at` | | `Tag` | Reusable keywords for classification (optional). | `id`, `name` | *Notes.* The schema file does not list dedicated version/ACL tables for documents; if `document_versioning`/`granular_permissions` introduces them, add to the canonical schema alongside `ProjectResource`. --- ### **4\) Supporting Configuration (frozen)** * **File size cap:** `MAX_BLUEPRINT_UPLOAD_MB = 150`. * **Allowed types:** `[".pdf", ".png", ".jpg", ".glb", ".gltf", ".stl"]`. * **Search backend:** `SEARCH_BACKEND = "postgres"` (tsvector indexing). * **Realtime layer:** Channels backend \= `channels_redis.core.RedisChannelLayer`. * **Media root/bucket:** `MEDIA_ROOT=/app/media/` (object storage mount used across modules). --- ### **5\) Routes & UI Surface** * Users access Stockage features inside project workspaces: **/projects** and **/projects/\[slug\] → “Blueprints” tab** for uploads, previews, version/history, and permissions UI. Route ownership lives with keenKonnect. --- ### **6\) Runtime & Real‑Time** * **Object storage & previews.** Files live in the media bucket; optional workers can generate previews/conversions (e.g., glTF thumbnails) per the technical spec’s storage guidance. * **WebSockets.** Document events publish to project channel groups so collaborators see updates without refresh. --- ### **Summary** Stockage provides `secure_document_storage`, `document_versioning`, `intelligent_indexing`, `real_time_sync`, and `granular_permissions`. Today’s schema centers on `ProjectResource` within `/projects/[slug]` workspaces, governed by `ProjectTeam` roles, with search on PostgreSQL tsvectors and real‑time updates via Channels/Redis. Version and per‑document ACL tables can be added when those services move from interface to implementation. ================================================================================================ FILE: Rejean-en/Konnaxion/Kollective-Intelligence/EkoH.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ea74104a4cad1fdba9142a3b156d8eab6c7c3b33f44e5119b4cffca75a6df0cd CONTENT_BYTES: 4821 ================================================================================================ **EkoH (Reputation & Expertise)** — first sub‑module under **Kollective Intelligence**. Implements seven core services with clear code‑names, supported by dedicated models and fixed parameters. --- ### **1\) Functional Services (and expected files)** Code‑name list per the v14 inventory; each code‑name maps to a Django service module (e.g., `services/scoring.py` contains `multidimensional_scoring`). | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Multidimensional Scoring | `multidimensional_scoring` | Compute per‑user/content scores across axes (quality, frequency, relevance, expertise). | `services/scoring.py` | | Criteria Customization | `configuration_weights` | Adjust scoring weights per axis/domain; read from stored configuration. | `services/configuration.py` (reads `ScoreConfiguration`) | | Automatic Contextual Analysis | `contextual_analysis` | AI tweaks sub‑scores in real time by topic/history/complexity signals. | `services/contextual_analysis.py` | | Dynamic Privacy | `privacy_settings` | Enforce anonymity/pseudonym modes while still exposing merit outputs. | `services/privacy.py` | | History & Traceability | `score_history` | Persist every recalculation/config change for auditability. | `services/history.py` (+ model hooks) | | Interactive Visualizations | `score_visualization` | Serve aggregated data for dashboards/skill maps/matrices. | `services/visualization.py` | | Expertise Classification by Field | `expertise_field_classification` | Bind scores to formal knowledge domains (taxonomy). | `services/expertise.py` | — ### **2\) Backend Functionalities** * **Reputation engine & triggers.** A Django service updates users’ domain‑specific Ekoh scores from platform activity; scheduled Celery jobs perform periodic recalculation, and event hooks apply immediate updates on impactful actions. * **Ethical multiplier.** An ethics score multiplies domain expertise to produce final influence weights (raises for constructive behavior, lowers for flagged behavior). * **Smart‑Vote integration.** Voting across modules (e.g., Ethikos) is weighted by the voter’s relevant Ekoh score; live results may be pushed via Channels. * **Cross‑module APIs.** Provides shared search/notifications/feed/recommendation surfaces that consume Ekoh signals (e.g., leaderboards, relevance). * **Quality controls.** Thresholds and moderation safeguards prevent brigading/spam from distorting reputation and consensus. — ### **3\) Database Models (OLTP)** Canonical tables powering EkoH scoring, ethics, audit, and privacy. | Table / Model | Purpose | Key fields | | ----- | ----- | ----- | | `ExpertiseCategory` | Domain taxonomy for expertise classification. | `id`, `name` | | `UserExpertiseScore` | Per‑user per‑domain raw/weighted score. | `id`, `user`, `category`, `raw_score`, `weighted_score` | | `UserEthicsScore` | Per‑user ethical multiplier (applied to expertise). | `user` (PK), `ethical_score` | | `ScoreConfiguration` | Named weights/coefficients (global or per field). | `id`, `weight_name`, `weight_value`, `field` | | `ContextAnalysisLog` | AI context adjustments applied to scores. | `id`, `entity_type`, `entity_id`, `field`, `input_metadata` (JSON), `adjustments_applied` (JSON) | | `ConfidentialitySetting` | User privacy level for identity display near scores. | `user` (PK), `level` (enum: public/pseudonym/anonymous) | | `ScoreHistory` | Full audit trail of score changes. | `id`, `merit_score` (FK), `old_value`, `new_value`, `change_reason` | — ### **4\) Supporting Configuration (frozen)** Finalized parameters for EkoH engine and domain taxonomy. * **Initial axis weights:** `quality=1.000`, `expertise=1.500`, `frequency=0.750` → used by `multidimensional_scoring`. * **Ethical multiplier bounds:** floor `0.20`, cap `1.50`. * **Expertise domains:** `EXPERTISE_DOMAIN_CHOICES` (26 ISO‑based domains; seeded fixtures). — ### **5\) Schedules & runtime** * **Periodic recomputation:** Celery Beat tasks (nightly/interval) to refresh Ekoh scores and any precomputed leaderboards; monitored in CI/ops. * **Realtime delivery:** Optionally push score/leaderboard deltas or weighted results via Django Channels \+ Redis. — ### **Summary** EkoH exposes seven concrete services (`multidimensional_scoring`, `configuration_weights`, `contextual_analysis`, `privacy_settings`, `score_history`, `score_visualization`, `expertise_field_classification`) mapped to Django service modules; it persists expertise/ethics/traceability/privacy via dedicated tables and operates under fixed, reviewable parameters. It is the weighting backbone for Smart‑Vote and cross‑module relevance, with periodic recomputation and optional realtime updates. ================================================================================================ FILE: Rejean-en/Konnaxion/Kollective-Intelligence/Smart-Vote.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 903fe4ccb3692289fc87b21039dfb4e52adf5b46f43dd6c2271d339bbc0e8dff CONTENT_BYTES: 4299 ================================================================================================ **Smart Vote (Weighted Voting System)** — second sub‑module under **Kollective Intelligence**. Implements six core services with explicit code‑names, backed by vote/aggregation models, global parameters, and analytics pipelines. --- ### **1\) Functional Services (and expected files)** | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Dynamic Weighted Voting | `dynamic_weighted_vote` | Re‑weights each vote in real time using the voter’s EkoH domain weight. | `services/dynamic_weighted_vote.py` | | Flexible Voting Modalities | `voting_modalities` | Supports approval, ranking, rating, preferential ballots; modality parameters drive tally logic. | `services/voting_modalities.py` | | Emerging Expert Detection | `emerging_expert_detection` | Flags users whose EkoH score is rising sharply to surface new experts. | `tasks/emerging_expert_detection.py` | | Transparency of Results | `vote_transparency` | Publishes raw and weighted totals with context (no private data). | `services/vote_transparency.py` | | Advanced Result Visualizations | `vote_result_visualization` | Produces histograms, distributions, network graphs for outcomes. | `services/vote_result_visualization.py` | | Cross‑Module Integration | `cross_module_vote_integration` | Makes Smart Vote available across modules (e.g., debates, content, projects). | `services/cross_module_vote_integration.py` | --- ### **2\) Backend Functionalities** * **Vote intake & aggregation.** API records a per‑user vote on a target (`target_type`, `target_id`), applies EkoH‑weighted scoring, and updates an aggregated result object; concurrency‑safe updates with immediate read‑back for live UIs. * **Modalities engine.** Aggregation logic switches by `VoteModality` parameters (approval/rating/ranking/preferential); modality configuration stored and read at runtime. * **Realtime delivery.** Updated tallies pushed via Django Channels \+ Redis for live dashboards and pages displaying current consensus. * **Cohort/segment views.** Aggregator exposes filtered outcomes (e.g., experts‑only, verified‑only) when the calling module requests segmented results. * **Cross‑module linkage.** Generic mapping allows any app entity to become a vote target (e.g., debates, consultations, projects). --- ### **3\) Database Models (OLTP)** | Table / Model | Purpose | Key fields | | ----- | ----- | ----- | | `Vote` | Stores each user vote (raw value \+ weighted value). | `id`, `user`, `target_type`, `target_id`, `raw_value`, `weighted_value` | | `VoteModality` | Config for voting modes (approval, ranking, rating, preferential). | `id`, `name`, `parameters` (JSON) | | `EmergingExpert` | Flags users with sharp reputation gains. | `id`, `user`, `detection_date`, `score_delta` | | `VoteResult` | Aggregated totals per target (cumulative weighted sums \+ counts). | `id`, `target_type`, `target_id`, `sum_weighted_value`, `vote_count` | | `IntegrationMapping` | Cross‑module link from vote context to other modules’ objects. | `id`, `module_name`, `context_type`, `mapping_details` (JSON) | --- ### **4\) Supporting Configuration (frozen)** * **Vote modalities:** `"approval" | "ranking" | "rating" | "preferential"` (`VOTE_MODALITY_CHOICES`). * **Emerging expert threshold:** `+15%` EkoH delta over 30 days. * **Strong consensus threshold:** `≥ 75%` weighted agreement. --- ### **5\) Schedules, Analytics & Runtime** * **Realtime channel layer:** `channels_redis.core.RedisChannelLayer` used for live result pushes. * **Analytics ETL:** `etl_smart_vote` runs every **10 minutes** to load OLTP deltas into `smart_vote_fact`; retention **5 years**; cached views power `/reports/smart-vote`. * **UI surfaces:** * **Konsensus Center** (end‑user portal with live polls/results): `/konsensus`. * **Insights dashboard (read‑only analytics):** `/reports/smart-vote`. --- ### **Summary** Smart Vote provides modality‑aware, EkoH‑weighted voting with real‑time aggregation, transparent reporting, and cross‑module targeting. Its models (`Vote`, `VoteModality`, `VoteResult`, `EmergingExpert`, `IntegrationMapping`), frozen parameters, and analytics pipelines make it the consensus backbone across the platform. ================================================================================================ FILE: Rejean-en/Konnaxion/KonnectED/CertifiKation.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 13b57e8f28ae99e0cf81cf206d39b2df135228dcf10f893b5cf92664863c5751 CONTENT_BYTES: 4816 ================================================================================================ **CertifiKation (Skills & Certification)** — sub‑module under **KonnectED**. Implements five core services with fixed code‑names and routes exposed via the DRF backend and `/certs` UI flows. --- ### **1\) Functional Services (and expected files)** Code‑names come from the v14 Functional Inventory; each maps 1‑to‑1 to a Django service module (e.g., `services/.py`). | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Certification Paths | `certification_path_management` | Define/maintain modular learning paths and competency milestones. | `services/certification_path_management.py` | | Automated Evaluation | `automated_evaluation` | Auto‑graded quizzes/tests and score calculation with metadata. | `services/automated_evaluation.py` | | Peer Validation | `peer_validation` | Mentor/peer approval workflow on submitted evidence tied to an evaluation. | `services/peer_validation.py` | | Skills Portfolio | `skills_portfolio` | User portfolio of validated skills and artifacts, surfaced in “My Certificates.” | `services/skills_portfolio.py` | | Interoperability (LMS) | `certification_interoperability` | Map/import/export certifications with external LMS/registries. | `services/certification_interoperability.py` | The inventory explicitly lists these five services for CertifiKation and describes the code‑name→service convention used across modules. --- ### **2\) Backend Functionalities** * **Program & curriculum management.** CRUD for *CertificationPath* (name, description), ordering of steps, and visibility rules; exposed via DRF to power `/certs` → “Programs.” * **Evaluations & scoring.** Creating an *Evaluation* per user/path records `raw_score` and structured `metadata` (e.g., answers, rubric). Pass/fail uses frozen thresholds (see CERT\_PASS\_PERCENT), and retries respect a cooldown policy. * **Peer validation workflow.** *PeerValidation* ties to an Evaluation; authorized peers issue an `approved`/`rejected` decision that finalizes the evaluation outcome when required by the path. * **Certificate issuance.** On successful completion (auto‑evaluation and/or peer validation), a **Certificate** record (core/common model) links the user to the earned credential for display and download from `/certs` → “My Certificates.” * **Skills portfolio linkage.** Portfolio items (evidence, learning artifacts) can be attached to programs and evaluations so achievements surface coherently in the user’s skill profile. * **Interoperability.** *InteropMapping* maps internal paths to external systems’ identifiers to support import/export and verification workflows. * **Permissions & roles.** Uses the platform’s unified JWT/RBAC and Krowd user model; module actions inherit common auth and moderation controls. --- ### **3\) Database Models** These are the concrete tables tied to CertifiKation features; “Certificate” is defined at the common/core layer and consumed here. | Table / Model | Purpose | Key fields | | ----- | ----- | ----- | | **CertificationPath** | Defines a named certification/learning path. | `id`, `name`, `description` | | **Evaluation** | Stores a user’s attempt and score on a path. | `id`, `user`, `path`, `raw_score`, `metadata` (JSON) | | **PeerValidation** | Peer/mentor decision for an Evaluation. | `id`, `evaluation`, `peer`, `decision` (enum) | | **Portfolio** (KonnectED) | User skill/evidence showcase used by skills\_portfolio. | `id`, `user`, `title`, `description`, `items` (M2M) | | **InteropMapping** | Links internal CertificationPath to external LMS IDs. | `id`, `local_certification`, `external_system`, `external_id` | | **Certificate** (Core) | Issued credential linking user↔certification. | fields per core “Certificate (CertifiKation)” model | Model purposes/fields are specified in the v14 schema reference and the core database description. --- ### **4\) Supporting Configuration** * **Pass threshold:** `CERT_PASS_PERCENT = 80%` (applied by automated\_evaluation/issuance logic). * **Retry policy:** `QUIZ_RETRY_COOLDOWN_MIN = 30` minutes between failed attempts. * **Module routes:** `/certs` reserved for the CertifiKation Center (Programs, My Certificates). --- ### **Summary** CertifiKation delivers end‑to‑end credentialing: define programs (*CertificationPath*), assess learners (*Evaluation*), adjudicate evidence (*PeerValidation*), issue credentials (core *Certificate*), and present outcomes via portfolios and the `/certs` flows. Its five named services (`certification_path_management`, `automated_evaluation`, `peer_validation`, `skills_portfolio`, `certification_interoperability`) are version‑locked in the inventory and backed by concrete schema and parameters. ================================================================================================ FILE: Rejean-en/Konnaxion/KonnectED/Knowledge.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: d31bdf7b591cab7408f9112d149d2deddf9fe1a5aa7a2dc3fd17a7bad9ffcdcd CONTENT_BYTES: 4457 ================================================================================================ **Knowledge (Collaborative Learning Library)** — sub‑module under **KonnectED**. Implements five concrete services with code‑names, backed by specific tables and fixed parameters, and exposed through the **/learn** and **/course/** flows. --- ### **1\) Functional Services (and expected files)** Code‑name → service module mapping follows the v14 inventory convention. | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Collaborative Library | `library_resource_management` | CRUD, classify, and publish library resources; enforce type enums and moderation. | `services/library_resource_management.py` | | Personalized Recommendations | `personalized_recommendation` | Suggest resources per learner profile, usage, and expertise signals. | `services/personalized_recommendation.py` | | Co‑Creation Tools | `content_co_creation` | Real‑time authoring/versioning of lessons and media with contribution workflow. | `services/content_co_creation.py` | | Thematic Forums | `thematic_forum` | Subject‑based discussion boards tied to resources and courses. | `services/thematic_forum.py` | | Learning Progress Tracking | `learning_progress_tracking` | Track per‑user progress and completion across resources/lessons. | `services/learning_progress_tracking.py` | --- ### **2\) Backend Functionalities** * **Library management & contribution.** Resource CRUD with enforced content types, draft/publish states, and per‑user draft caps; surfaced in **/learn**. * **Search & discovery.** Full‑text search over titles/descriptions using the platform’s PostgreSQL tsvector backend; results feed the library listing and global search. * **Recommendations.** Periodic or on‑demand generation of **KnowledgeRecommendation** rows per user; ranking blends popularity, recency, and profile relevance. * **Co‑creation workflow.** Collaborative editing spaces for lessons/media with versioned **CoCreationContribution** entries; authors can iterate before publishing to the library. * **Forums.** Topic and post threads by theme/subject with moderation hooks; linked from resource or course views and listed under **/learn**. * **Progress tracking & player.** The **/course/\[slug\]** player reads/writes **LearningProgress** to drive completion %, resumes, and achievements. * **Offline distribution.** Scheduled packaging of selected knowledge content for low‑connectivity environments. --- ### **3\) Database Models** Custom tables for Knowledge, Co‑Creation, and Forums; plus recommendation/progress records. | Table / Model | Purpose | Key fields | | ----- | ----- | ----- | | **KnowledgeResource** | Canonical library item (article, video, lesson, quiz, dataset). | `id`, `title`, `type` *(enum)*, `url`, `author` | | **KnowledgeRecommendation** | Records a recommended resource for a user. | `id`, `user`, `resource`, `recommended_at` | | **LearningProgress** | Per‑user progress for a resource/lesson. | `id`, `user`, `resource`, `progress_percent` *(unique per user+resource)* | | **CoCreationProject** | Collaborative content project container. | `id`, `title`, `status` *(enum)* | | **CoCreationContribution** | Individual draft/edit within a project. | `id`, `project`, `user`, `content` | | **ForumTopic** | Thematic forum thread (subject/question). | `id`, `title`, `category`, `creator` | | **ForumPost** | Post/reply within a topic. | `id`, `topic`, `author`, `content` | --- ### **4\) Supporting Configuration & Routes** * **Allowed content types (enum):** `article`, `video`, `lesson`, `quiz`, `dataset`. * **Draft cap:** `MAX_CONTRIBUTION_DRAFTS = 10` per user. * **Search backend:** `SEARCH_BACKEND = "postgres"` (tsvector). * **Offline packaging schedule:** `OFFLINE_PACKAGE_CRON = 0 3 * * SUN`. * **Navigation:** **/learn** (Catalog, Recommendations, Offline Download) and **/course/\[slug\]** (Course Player: Lessons, Assessments, Progress). --- ### **Summary** Knowledge delivers the learning library and its social layer: resource management, personalized recommendations, collaborative authoring, themed forums, and progress tracking. It provides five named services (`library_resource_management`, `personalized_recommendation`, `content_co_creation`, `thematic_forum`, `learning_progress_tracking`) mapped to Django modules and backed by concrete tables and parameters, integrated with **/learn** and **/course/** UX. ================================================================================================ FILE: Rejean-en/Konnaxion/Kreative/Konservation.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 8e659b5a1b8023676fefe830c48e5a312446797cdd4f2a0442fb8572f70730e1 CONTENT_BYTES: 5664 ================================================================================================ **Konservation (Creative Content & Cultural Preservation)** — sub‑module under **Kreative**. Implements five core services with named code‑functions, backed by dedicated models and frozen parameters. --- ### **1\) Functional Services (and expected files)** Code‑names follow the v14 inventory and map 1:1 to service modules. | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Digital Archives | `digital_archive_management` | Ingest, store, and retrieve digitized artworks and heritage media; handle provenance and rights metadata. | `kreative/services/digital_archive.py` | | Virtual Exhibitions | `virtual_exhibition` | Build interactive online galleries/VR rooms from curated sets; enforce per‑room capacity; publish exhibits. | `kreative/services/virtual_exhibition.py` | | Documentation Base | `archive_documentation` | Manage bios, provenance notes, and supplemental documents attached to artworks/galleries. | `kreative/services/archive_documentation.py` | | AI‑Enriched Catalogue | `ai_enriched_catalogue` | Auto‑classify artworks, generate tags/labels and fill style/medium using ML; writes to tagging/metadata. | `kreative/services/catalogue_ai.py` and `kreative/tasks/ai_enrichment.py` | | Cultural Partners Integration | `cultural_partner_integration` | Import/sync collections from partner museums/heritage systems; map external metadata to local schema. | `kreative/services/partner_integration.py` and `kreative/tasks/partner_ingest.py` | Mapping guidance (“each code name maps to a service module”) per the Functional Code‑Name Inventory. --- ### **2\) Backend Functionalities** * **Artwork & media lifecycle.** Upload, validate, and persist artworks; generate multiple image renditions for fast delivery; enforce upload size and allowed media types. * **Curation & exhibitions.** Curators assemble **Galleries** (ordered sets) and publish **Virtual Exhibitions** with capacity limits per room. * **Tagging & discovery.** Global **Tag** vocabulary with many‑to‑many mapping to artworks; AI service can propose tags and styles. * **Heritage submissions.** Community submits **TraditionEntry** items (media \+ description \+ region) to the archive; moderator approval workflow. * **Rights, privacy, and moderation.** NSFW flag on upload; shared moderation policies across modules; provenance and creator attribution preserved. * **API & stack.** Exposed via Django REST Framework to the Next.js frontend; object storage for media; background workers for image/AI pipelines. --- ### **3\) Database Models (OLTP)** Canonical tables for Konservation content and curation. | Table / Model | Purpose | Key fields (excerpt) | | ----- | ----- | ----- | | `KreativeArtwork` | A single artwork or creative work (image/video/audio/other). | `id`, `artist` (FK User), `title`, `description`, `media_file`, `media_type` (ENUM), `year`, `medium`, `style` | | `Tag` | Global tagging vocabulary reused by artworks (and other content). | `id`, `name` (unique) | | `ArtworkTag` | Join table linking artworks ↔ tags (M2M; unique per pair). | `id`, `artwork` (FK), `tag` (FK) | | `Gallery` | Curated collection or exhibition container. | `id`, `title`, `description`, `created_by` (FK User, nullable), `theme`, `created_at` | | `GalleryArtwork` | Through‑table to place artworks in a gallery with order. | `id`, `gallery` (FK), `artwork` (FK), `order` | | `TraditionEntry` | Cultural heritage submission for long‑term archive. | `id`, `title`, `description`, `region`, `media_file`, `submitted_by` (FK, nullable), `submitted_at`, `approved` (bool), `approved_by` (FK, nullable), `approved_at` | Models live under the Kreative app (e.g., `kreative/models/artwork.py`, `gallery.py`, `tradition.py`). --- ### **4\) Supporting Configuration (frozen)** Operational parameters and invariants affecting Konservation features. * **ARTWORK\_MAX\_IMAGE\_MB:** **50 MB** — upload limit for image media. * **ARTWORK\_RESOLUTIONS:** **\[256, 1024, 2048\]** px — renditions generated on ingest. * **VIRTUAL\_GALLERY\_CAPACITY:** **24 artworks / room** — enforced by `virtual_exhibition`. * **NSFW\_FLAG\_REQUIRED:** boolean (default **False**) — surfaced in upload form and display gates. * **MEDIA\_ROOT:** `/app/media/` — single bucket mount for all modules (shared invariant). --- ### **5\) Routes & Ownership (UI)** Top‑level navigation and page ownership for this sub‑module. * **/kreative** — Creativity Hub (tabs: Gallery, Incubator, Virtual Exhibitions). * **/art/\[id\]** — Artwork Sheet (details, comments, metadata). * **/archive** — Konservation Archive (Heritage, Partners). --- ### **6\) DevOps & Tasks** * **Image pipeline.** Celery task generates `ARTWORK_RESOLUTIONS` on upload; stores renditions alongside originals in object storage. * **AI enrichment.** Scheduled worker applies `ai_enriched_catalogue` to new/updated artworks (tags, style/medium suggestions). * **Partner ingest.** Periodic sync jobs fetch external collections and map metadata via `cultural_partner_integration`. * **Publishing.** Exhibition build step compiles gallery selections into front‑end consumables (JSON descriptors / assets), respecting capacity limits. --- ### **Summary** Konservation provides **digital archiving**, **virtual exhibitions**, **documentation**, **AI‑assisted cataloguing**, and **partner integrations** via the five services above, grounded in the `KreativeArtwork`, `Gallery`, `Tag/ArtworkTag`, and `TraditionEntry` models and governed by fixed upload, rendition, and exhibition parameters. ================================================================================================ FILE: Rejean-en/Konnaxion/Kreative/Kontact.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: cf3b050bc4b419a986505dab954a53de7130301638abb7acd7aa3d5cd0b7193f CONTENT_BYTES: 4628 ================================================================================================ **Kontact (Collaboration & Networking)** — sub‑module under **Kreative**. Implements **five core services** with stable code‑names and module ownership under the `/connect` and `/profile/[user]` routes. --- ### **1\) Functional Services (and expected files)** Code‑names are canonical; each maps 1:1 to a Django service module consumed by DRF views and Celery tasks. | Display name | Code name / service | Purpose / behavior | Likely file or module | | ----- | ----- | ----- | ----- | | Professional Profiles | `professional_profile` | Rich public profiles for creators/diffusers: bio, skills, portfolio links; integrates artwork and tags for discovery. | `kreative/services/professional_profile.py` | | Intelligent Matching | `intelligent_matching` | Recommends people to follow/contact or invite into collaborations based on skills, tags, and activity signals (Ekoh context optional). | `kreative/services/intelligent_matching.py` | | Collaboration Workspaces | `collaboration_workspace` | Lightweight networking‑context rooms (chat/notes/canvas) to meet, plan, and co‑create; reuses real‑time infra. | `kreative/services/collaboration_workspace.py` | | Opportunities Board | `opportunity_announcement` | Post/browse residencies, exhibitions, calls, jobs; searchable by tags, region, dates. | `kreative/services/opportunity_announcement.py` | | Reviews & Endorsements | `partner_recommendation` | Post‑engagement endorsements/ratings to establish trust and reputation between collaborators/hosts. | `kreative/services/partner_recommendation.py` | --- ### **2\) Backend Functionalities** * **Profiles & portfolios.** Exposes read/write APIs for creator profiles, linking to existing creative assets (artworks, tags) for rich portfolios and searchability. * **People matching.** `intelligent_matching` ranks suggested contacts via skills/tags overlap and activity; tunable top‑N, and optional Ekoh/Smart‑Vote signals when relevant. * **Real‑time meetups.** `collaboration_workspace` provisions ephemeral rooms (DM/group), built on the same Channels/Redis stack used elsewhere; participant cap enforced at runtime. * **Opportunity lifecycle.** `opportunity_announcement` provides CRUD for postings (type, location, dates, attachments), listing/search, and status (open/closed/filled). * **Trust signals.** `partner_recommendation` lets collaborators leave structured endorsements after a workspace or engagement concludes; surfaced on profile pages. * **Routes & ownership.** UI/API bound to **/connect** (People, Opportunities, Workspace) and **/profile/\[user\]** (public profile), per navigation invariants. --- ### **3\) Database Models** The database reference explicitly lists the **CollabSession** table under Kreative/Kontact. Profiles, opportunities, and endorsements use existing/core objects and Kontact app models not enumerated in that reference. | Table / Model | Purpose | Key fields (excerpt) | | ----- | ----- | ----- | | `CollabSession` | Real‑time collaborative session (networking/co‑creation room). | `id`, `name`, `host (FK User)`, `session_type (ENUM)`, `started_at`, `ended_at`, `final_artwork (FK KreativeArtwork, nullable)` | | *(Reused)* `KreativeArtwork` | Portfolio items surfaced on profiles (read‑only in Kontact). | `id`, `artist (FK)`, `title`, `media_file`, `media_type`, `style` | | *(Reused)* `Tag` / `ArtworkTag` | Skills/genre tags used for discovery/matching. | `Tag.name (unique)`; `ArtworkTag (artwork, tag)` | *Note:* Only `CollabSession` is listed under Kontact in the v14 schema reference; other Kontact records (profiles, opportunities, recommendations) are implemented at the app level and/or reuse core tables. --- ### **4\) Supporting Configuration** Fixed parameters and route invariants that affect Kontact behavior. * **COLLAB\_CANVAS\_MAX\_USERS:** **6** simultaneous editors in a real‑time room. * **MEDIA\_ROOT:** `/app/media/` for attachments (shared across modules). * **Routes reserved:** `/connect`, `/profile/[user]` owned by Kreative/Kontact; additional nested tabs do not create new top‑level routes. --- ### **Summary** Kontact delivers networking‑centric capabilities via five services — `professional_profile`, `intelligent_matching`, `collaboration_workspace`, `opportunity_announcement`, `partner_recommendation` — integrated with the Kreative domain and routed under `/connect` and `/profile/[user]`. Data persists primarily through `CollabSession` and reused creative/Tag tables; real‑time rooms and matching leverage the platform’s DRF \+ Channels \+ Redis stack and frozen configuration. ================================================================================================ FILE: Rejean-en/Konnaxion/Technical/Konnaxion-Technical-Architecture-And-Services.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 4e0b3545a2cfd901a295378112cb2ed0b66eae0e5af2860b0d4014b89a526f5c CONTENT_BYTES: 17102 ================================================================================================ # Konnaxion – Technical Architecture & Services This page collects the **technical details** of Konnaxion: service code‑names, core models, configuration parameters, routing invariants, and cross‑module infrastructure. It complements: * the repository **README**, which focuses on vision, mythology, and high‑level modules * the wiki **hub page**, which explains civic workflows and navigation * the individual module pages (Knowledge, CertifiKation, Korum, etc.), which describe each sub‑module functionally Use this page as the reference for development and integration work. --- ## 1. Platform overview ### 1.1 KOA module map Konnaxion’s architecture is organized into six top‑level modules: * **KonnectED** – learning, knowledge, and certification * **Ethikos** – structured debates and civic consultations * **Kreative** – culture, preservation, and professional networks * **keenKonnect** – project workspaces and storage * **Kollective Intelligence** – reputation and voting (EkoH, Smart Vote) * **System / Core** – cross‑cutting auth, storage, search, analytics Each KOA module is implemented as one or more Django apps with: * **service code‑names** (e.g. `multidimensional_scoring`, `public_consultation`) mapping 1‑to‑1 to service modules * **OLTP models** described in the v14 schema reference * **frozen configuration parameters** (thresholds, limits, routes) ### 1.2 Shared technology stack Across modules, the technical stack is consistent: * **Backend**: Django + Django REST Framework * **Realtime**: Django Channels with Redis (`channels_redis.core.RedisChannelLayer`) * **Data store**: PostgreSQL with tsvector full‑text search * **Background tasks**: Celery (ETL, AI enrichment, packaging, recomputation) * **Object storage**: `/app/media/` root, typically backed by S3/MinIO * **Front‑end**: routes reserved per module (`/learn`, `/certs`, `/debate`, etc.) --- ## 2. Cross‑module infrastructure ### 2.1 Service code‑name convention Every sub‑module defines **named services** that are stable integration points. Examples: * Korum: `structured_debate`, `ai_clone_management`, `comparative_argument_analysis`, `public_debate_archive`, `automated_debate_summary` * Smart Vote: `dynamic_weighted_vote`, `voting_modalities`, `emerging_expert_detection`, `vote_transparency`, `vote_result_visualization`, `cross_module_vote_integration` * EkoH: `multidimensional_scoring`, `configuration_weights`, `contextual_analysis`, `privacy_settings`, `score_history`, `score_visualization`, `expertise_field_classification` * Knowledge: `library_resource_management`, `personalized_recommendation`, `content_co_creation`, `thematic_forum`, `learning_progress_tracking` Code‑names map 1‑to‑1 to service modules (e.g. `services/dynamic_weighted_vote.py`), and are referenced by tasks, API endpoints, and configuration. ### 2.2 Routing invariants Top‑level routes are **owned** by specific modules and treated as invariants: * `/learn`, `/course/[slug]` → KonnectED / Knowledge * `/certs` → KonnectED / CertifiKation * `/debate`, `/ethikos/insights` → Ethikos / Korum * `/consult` → Ethikos / Konsultations * `/projects`, `/projects/[slug]` → keenKonnect / Konstruct + Stockage * `/kreative`, `/art/[id]`, `/archive` → Kreative / Konservation * `/connect`, `/profile/[user]` → Kreative / Kontact * `/konsensus`, `/reports/smart-vote` → Kollective Intelligence / Smart Vote No other module should claim these top‑level paths. ### 2.3 Storage and media * **Media root**: `MEDIA_ROOT=/app/media/` is shared across modules. * **File size & types** are fixed per context: * Stockage / Konstruct: `MAX_BLUEPRINT_UPLOAD_MB = 150`, types `[".pdf", ".png", ".jpg", ".glb", ".gltf", ".stl"]` * Konservation: `ARTWORK_MAX_IMAGE_MB = 50`, `ARTWORK_RESOLUTIONS = [256, 1024, 2048]` px Storage is typically an object store (S3/MinIO) behind the media path. ### 2.4 Search * Knowledge and Stockage explicitly use PostgreSQL full‑text search (`SEARCH_BACKEND = "postgres"`) for library resources and documents. * Tags (`Tag`, `ArtworkTag`) provide a shared taxonomy layer across Kreative and keenKonnect. ### 2.5 Realtime and background jobs * **Django Channels + Redis** power: * live stance and result updates in Korum and Konsultations * real‑time tallies in Smart Vote * project chat, notifications, and document events in Konstruct and Stockage * collaboration rooms in Kontact * **Celery tasks & schedules** include: * `etl_smart_vote` every 10 minutes, with ~5‑year retention for facts * periodic EkoH score recomputation and leaderboard refresh * weekly offline packaging for Knowledge (`OFFLINE_PACKAGE_CRON = 0 3 * * SUN`) * image rendition, AI enrichment, and partner ingest for Konservation --- ## 3. Module–by–module technical summary ### 3.1 KonnectED #### 3.1.1 Knowledge – Collaborative Learning Library **Services** * `library_resource_management` – CRUD and classify `KnowledgeResource`; enforce type enum. * `personalized_recommendation` – compute `KnowledgeRecommendation` per user. * `content_co_creation` – manage `CoCreationProject` and `CoCreationContribution` drafts. * `thematic_forum` – forums via `ForumTopic` and `ForumPost`. * `learning_progress_tracking` – track `LearningProgress` (per user + resource). **Core models** * `KnowledgeResource(id, title, type, url, author)` * `KnowledgeRecommendation(user, resource, recommended_at)` * `LearningProgress(user, resource, progress_percent)` * `CoCreationProject`, `CoCreationContribution` * `ForumTopic`, `ForumPost` **Key configuration** * Content types: `article | video | lesson | quiz | dataset` * `MAX_CONTRIBUTION_DRAFTS = 10` per user * Search backend: `SEARCH_BACKEND = "postgres"` * Offline packaging: `OFFLINE_PACKAGE_CRON = 0 3 * * SUN` **Routes** * `/learn` – catalog, recommendations, offline download * `/course/[slug]` – course player (lessons, progression) #### 3.1.2 CertifiKation – Skills & Certification **Services** * `certification_path_management` – manage `CertificationPath`. * `automated_evaluation` – create `Evaluation` with `raw_score` and metadata. * `peer_validation` – handle `PeerValidation` decisions. * `skills_portfolio` – connect to `Portfolio` and core `Certificate` records. * `certification_interoperability` – manage `InteropMapping` with external LMS/registries. **Core models** * `CertificationPath(id, name, description)` * `Evaluation(user, path, raw_score, metadata)` * `PeerValidation(evaluation, peer, decision)` * `Portfolio(user, title, description, items)` * `InteropMapping(local_certification, external_system, external_id)` * `Certificate` (core model for issued credentials) **Key configuration** * `CERT_PASS_PERCENT = 80` * `QUIZ_RETRY_COOLDOWN_MIN = 30` minutes * Routes reserved: `/certs` (Programs, My Certificates) --- ### 3.2 Ethikos #### 3.2.1 Korum – Structured Debates **Services** * `structured_debate`, `ai_clone_management`, `comparative_argument_analysis`, `public_debate_archive`, `automated_debate_summary`. **Core models** * `EthikosCategory` – thematic categories * `EthikosTopic` – debate topic/question * `EthikosStance(topic, user, value −3…+3)` * `EthikosArgument(topic, author, content, parent, side)` **Key configuration** * Stance scale: −3 … +3 (0 = neutral) * Expert cohort quorum: 12 distinct experts (EkoH threshold) * Moderation auto‑hide: 3 independent reports **Routes** * `/debate` – Debate Hub (Open / Archived / Start New) * `/ethikos/insights` – opinion analytics dashboards #### 3.2.2 Konsultations – Public Consultations & Feedback **Services** * `public_consultation`, `citizen_suggestion`, `weighted_consultation_vote`, `consultation_result_visualization`, `impact_tracking`. **Core models** * `Consultation(id, title, open_date, close_date, status)` * `CitizenSuggestion(consultation, author, content)` * `ConsultationVote(user, consultation, raw_value, weighted_value)` * `ConsultationResult(consultation, results_data JSONB)` * `ImpactTrack(consultation, action, status, date)` **Key configuration** * Ballot modalities: `approval | ranking | rating | preferential` * Consensus threshold (platform‑wide): ≥ 75% weighted agreement * Route namespace: `/consult` owned exclusively by Ethikos **Routes** * `/consult` – Consultation Hub (Live / Results / Suggest) * `/ethikos/insights` – shared with Korum analytics --- ### 3.3 Kreative #### 3.3.1 Konservation – Creative Content & Cultural Preservation **Services** * `digital_archive_management`, `virtual_exhibition`, `archive_documentation`, `ai_enriched_catalogue`, `cultural_partner_integration`. **Core models** * `KreativeArtwork(id, artist, title, description, media_file, media_type, year, medium, style)` * `Tag`, `ArtworkTag` (global tagging vocabulary and join table) * `Gallery`, `GalleryArtwork(order)` * `TraditionEntry(title, description, region, media_file, approved, approved_by)` **Key configuration** * `ARTWORK_MAX_IMAGE_MB = 50` * `ARTWORK_RESOLUTIONS = [256, 1024, 2048]` * `VIRTUAL_GALLERY_CAPACITY = 24` artworks/room * `NSFW_FLAG_REQUIRED` (bool, default `False`) * `MEDIA_ROOT = /app/media/` **Routes** * `/kreative` – Creativity Hub * `/art/[id]` – Artwork sheet * `/archive` – Konservation archive/partners #### 3.3.2 Kontact – Collaboration & Networking **Services** * `professional_profile`, `intelligent_matching`, `collaboration_workspace`, `opportunity_announcement`, `partner_recommendation`. **Core models** * `CollabSession(id, name, host, session_type, started_at, ended_at, final_artwork)` * Re‑uses `KreativeArtwork`, `Tag`, `ArtworkTag` for portfolios and tagging. **Key configuration** * `COLLAB_CANVAS_MAX_USERS = 6` * `MEDIA_ROOT = /app/media/` (shared) * Routes reserved: `/connect`, `/profile/[user]` **Routes** * `/connect` – People, Opportunities, Collaboration Workspace * `/profile/[user]` – public profile/portfolio --- ### 3.4 keenKonnect #### 3.4.1 Konstruct – Project Collaboration Spaces **Services** * `collaboration_space`, `project_task_management`, `real_time_document_editing`, `integrated_communication`, `ai_collaboration_analysis`. **Core models** * `Project(id, title, description, creator, category, status)` * `ProjectResource(project, title, url, added_by)` * `ProjectTask(project, title, description, assignee, status, due_date)` * `ProjectMessage(project, sender, content)` * `ProjectTeam(project, user, role, joined_at)` * `ProjectRating(project, user, rating, comment)` * `Tag` (shared) **Key configuration** * `MAX_BLUEPRINT_UPLOAD_MB = 150` * `ALLOWED_BLUEPRINT_TYPES = [".pdf", ".png", ".jpg", ".glb", ".gltf", ".stl"]` * `COLLAB_SPACE_MEMBER_CAP = 40` * `AI_SUGGESTION_TOP_N = 8` * `VIDEO_SESSION_PROVIDER = "livekit"` via `KC_VIDEO_PROVIDER` env var **Routes** * `/projects` – Project Studio (Browse, Create, My Projects) * `/projects/[slug]` – workspace (Overview, Tasks, Blueprints, Chat, AI Insights, Settings) #### 3.4.2 Stockage – Secure Repository & Versioned Storage **Services** * `secure_document_storage`, `document_versioning`, `intelligent_indexing`, `real_time_sync`, `granular_permissions`. **Core models** * `ProjectResource` (same as above; canonical file record) * `Project` and `ProjectTeam` for scoping and access control * `Tag` for classification **Key configuration** * `MAX_BLUEPRINT_UPLOAD_MB = 150` * Allowed types: `[".pdf", ".png", ".jpg", ".glb", ".gltf", ".stl"]` * `SEARCH_BACKEND = "postgres"` * Realtime layer: `channels_redis.core.RedisChannelLayer` * `MEDIA_ROOT = /app/media/` **Routes** * Exposed inside `/projects/[slug]` as the “Blueprints” tab. --- ### 3.5 Kollective Intelligence #### 3.5.1 EkoH – Reputation & Expertise **Services** * `multidimensional_scoring`, `configuration_weights`, `contextual_analysis`, `privacy_settings`, `score_history`, `score_visualization`, `expertise_field_classification`. **Core models** * `ExpertiseCategory(id, name)` * `UserExpertiseScore(user, category, raw_score, weighted_score)` * `UserEthicsScore(user, ethical_score)` * `ScoreConfiguration(weight_name, weight_value, field)` * `ContextAnalysisLog(entity_type, entity_id, field, input_metadata, adjustments_applied)` * `ConfidentialitySetting(user, level)` * `ScoreHistory(merit_score, old_value, new_value, change_reason)` **Key configuration** * Axis weights: `quality=1.000`, `expertise=1.500`, `frequency=0.750` * Ethical multiplier bounds: floor `0.20`, cap `1.50` * `EXPERTISE_DOMAIN_CHOICES`: 26 ISO‑based domains **Runtime** * Periodic recomputation via Celery Beat; optional realtime pushes of score/leaderboard deltas over Channels+Redis. #### 3.5.2 Smart Vote – Weighted Voting System **Services** * `dynamic_weighted_vote`, `voting_modalities`, `emerging_expert_detection`, `vote_transparency`, `vote_result_visualization`, `cross_module_vote_integration`. **Core models** * `Vote(user, target_type, target_id, raw_value, weighted_value)` * `VoteModality(name, parameters JSON)` * `EmergingExpert(user, detection_date, score_delta)` * `VoteResult(target_type, target_id, sum_weighted_value, vote_count)` * `IntegrationMapping(module_name, context_type, mapping_details)` **Key configuration** * Modalities: `approval | ranking | rating | preferential` * Emerging expert threshold: +15% EkoH delta over 30 days * Strong consensus threshold: ≥ 75% weighted agreement **Runtime & analytics** * Realtime results through Channels+Redis * ETL `etl_smart_vote` every 10 minutes → `smart_vote_fact` table, 5‑year retention * UI: `/konsensus` (live polls/results), `/reports/smart-vote` (analytics) --- ## 4. Data flows and integration ### 4.1 Reputation‑weighted voting * EkoH computes per‑user, per‑domain expertise and ethics scores with configurable weights and bounds. * Smart Vote reads those scores to weight `Vote` records via `dynamic_weighted_vote`, adjusting tallies per modality. * Korum and Konsultations integrate with Smart Vote to obtain EkoH‑weighted stances and ballots: * Korum aggregates `EthikosStance` using EkoH to compute expert cohort views. * Konsultations uses `weighted_consultation_vote` to store raw + weighted values per ballot. ### 4.2 Projects and documents * Konstruct manages projects, tasks, chat, and ratings via `Project*` models. * Stockage attaches documents and blueprints as `ProjectResource` records and handles versioning, indexing, and sync. * Real‑time events (file added/updated/removed; chat messages) are emitted via Channels+Redis to subscribed project workspaces. ### 4.3 Culture, archives, and networks * Konservation’s `KreativeArtwork`, `Gallery`, and `TraditionEntry` store creative and heritage outputs with tag‑based discovery. * Kontact reuses those artefacts and tags for profiles and matching, and stores collaboration sessions in `CollabSession`. * AI enrichment and partner ingest tasks update the archive and related metadata in the background. ### 4.4 Learning and certification * Knowledge hosts resources, forums, and co‑creation spaces and tracks progression per user/resource. * CertifiKation uses `CertificationPath`, `Evaluation`, and `PeerValidation` to issue `Certificate` records and fill user portfolios. * Although not strictly specified, these activities can feed EkoH via `multidimensional_scoring` as part of the platform‑wide reputation engine. --- ## 5. Analytics and insights * Smart Vote ETL (`etl_smart_vote`) is the central pipeline for decision analytics, aggregating delta changes from OLTP into a fact table with 5‑year retention, powering `/reports/smart-vote`. * Ethikos exposes `/ethikos/insights` to visualize debate stances and consultation outcomes, consuming Smart Vote facts and Korum/Konsultations data. * EkoH retains a full audit trail via `ScoreHistory` and `ContextAnalysisLog`, enabling longitudinal analysis of reputation evolution. --- ## 6. Contribution guidelines and invariants (technical) When extending or integrating with Konnaxion, the following invariants should be respected (all documented above): 1. **Do not change top‑level route ownership** (`/learn`, `/certs`, `/debate`, `/consult`, `/projects`, `/kreative`, `/connect`, `/konsensus`, `/reports/smart-vote`) without updating all dependent modules. 2. **Preserve service code‑names** (e.g. `dynamic_weighted_vote`, `multidimensional_scoring`); treat them as public, versioned integration points. 3. **Respect frozen parameter values** when relying on thresholds, caps, or schedule timings, or introduce new configuration entries in a documented way. 4. **Reuse shared infrastructure** (Channels+Redis, Celery, `/app/media/`, PostgreSQL tsvector) to keep behavior consistent and predictable. This page, together with the module‑specific wiki entries, should provide enough technical context to navigate, extend, and integrate the Konnaxion codebase. ================================================================================================ FILE: Rejean-en/Orgo/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 48c038899de70281128f79a40d8075f1a3402847451a010a3a37a9dcae1349ef CONTENT_BYTES: 8045 ================================================================================================ # Orgo System Overview This document provides a conceptual and technical map of the Orgo platform. It details how the system functions as a multi-tenant "nervous system" for organizations. Distinct from standard ticketing systems or CRMs, Orgo is designed for **sovereignty**. It is capable of operating as a "hermetic bubble"—completely independent of the public internet—powered by local intelligence. **Reference:** [Orgo Overview Presentation](https://administrative-efficienc-0u6vhrh.gamma.site/) ----- ## Conceptual Model Orgo is designed to solve the "messy signal" problem. Organizations receive inputs from dozens of channels (emails, chats, forms, sensors), often losing context or failing to spot patterns. Orgo standardizes this flow using the **SenTient Engine**: 1. **Listen:** Ingest signals from any source (Digital or Analog). 2. **Deconstruct (SenTient):** A local, offline engine converts linear natural language into structured **Wikidata concepts** without sending data to external AI clouds. 3. **Structure:** Convert these concepts into **Cases** (situations) and **Tasks** (actions). 4. **Route:** Assign work using a universal labeling syntax. 5. **Track:** Monitor execution against "Reactivity Time" (not just deadlines). Instead of hard-coding workflows for every department, Orgo provides a shared schema engine. A "Hospital" and a "Basketball Team" run on the same code, differentiated only by their **Profile** configuration. ----- ## Core Entities The system is strictly multi-tenant. * **Organization:** The top-level tenant (e.g., "Acme Corp" or "Local Shelter"). It owns all data, configuration, and policies. * **User:** An authenticated account (staff, volunteer, admin) capable of logging in and performing work. * **Person:** A profile representing a human subject (student, patient, employee). A Person is often the *subject* of a Case but may never log in. ----- ## The Autonomy Standard (The Bubble) Orgo is built on the philosophy of the **Hermetic Bubble**. While it can bridge to external networks (like Konnaxion) when desired, it does not *rely* on them. * **Internet Independence:** The core logic, database, and processing engine run entirely on private infrastructure (or local nodes). * **Zero Data Leaks:** Because it uses **SenTient** for local processing instead of calling public APIs (like OpenAI or Google), sensitive organizational data never leaves the perimeter. * **Resilience:** Operations continue seamlessly during internet blackouts or grid failures. ----- ## The Workflow Pipeline: Signals → Cases → Tasks ### 1. Signals Inputs enter the system via the **Gateway**. * **Email:** Parsed via IMAP/SMTP (stripping signatures, normalizing threads). * **API:** Direct POST requests from external tools. * **Offline Node:** Batched imports from local tablets or sensors within the bubble. ### 2. The Engine (SenTient + Workflow) The incoming signal is processed by **SenTient** to extract intent and entities, then evaluated by the **Workflow Engine** against **Flow Rules**. It determines: * Does this require a new **Case**? * Does this spawn specific **Tasks**? * What is the **Label** (routing address)? * What is the **Severity** and **Reactivity Time**? ### 3. Objects * **Case:** A container for a specific situation (e.g., "Water Leak in Sector 7" or "Harassment Complaint #99"). It holds the narrative, location, tags, and aggregate status. * **Task:** An atomic unit of work linked to a Case. It follows a strict state machine (`pending` → `in_progress` → `completed`). ----- ## Routing System: The Label Orgo uses a deterministic labeling system to route information. A label is a single string that encodes **Scope**, **Topic**, **Intent**, and **Role**. **Format:** `..` ### The Base (Vertical Scope) Defines *who* needs to see this. * `1` - CEO / Executive * `11` - Department Head * `101` - Team Lead * `1001` - Staff / Operative * *(Broadcast variants: `10`, `100`, `1000`)* ### The Taxonomy (Decimal) * **Category (1st digit):** The domain (e.g., `9` = Crisis, `5` = Training, `1` = Ops). * **Subcategory (2nd digit):** The intent (e.g., `1` = Request, `4` = Report, `5` = Broadcast). ### Example > **`1001.91.Operations.Safety`** > > * **1001:** Staff level. > * **9:** Crisis/Emergency category. > * **1:** Request (Action required). > * **Operations.Safety:** The functional team responsible. ----- ## Profiles & Configuration Orgo avoids custom code for every client by using **Profiles**. A Profile is a bundle of YAML configuration parameters that dictates system behavior. **Configurable Knobs:** * **Reactivity Windows:** Does "High Priority" mean 1 hour (Hospital) or 3 days (Volunteer Group)? * **Privacy:** Default visibility (Open-by-default vs. Need-to-know). * **Escalation:** How quickly does an ignored task jump to the next vertical level? * **Retention:** Log storage duration. ----- ## Technical Architecture The codebase is organized into four distinct layers. ### 1. Core Services The monolithic engine that powers the platform. * **SenTient Integration:** The local NLP module for entity extraction and signal classification. * `TaskHandler`: Enforces state machines and SLA tracking. * `WorkflowEngine`: Matches signals to rules. * `Notifier`: Handles outbound communication (Email, Push). * `Logger`: Centralized, normalized audit logging. ### 2. Domain Modules Thin adapters that define domain-specific logic without owning separate databases. * **Maintenance:** Defines assets, locations, and repair workflows. * **Care/HR:** Defines personnel, privacy rules, and intake flows. * **Groups:** Defines classes, rosters, and schedules. ### 3. Insights Module The analytical brain. It uses a Star Schema (`fact_cases`, `dim_time`, `dim_location`) to answer questions like "Which department creates the most critical alerts?" ### 4. Infrastructure Handles the "plumbing": Database connections (Postgres/SQLite), offline synchronization logic, and Docker containerization for independent deployment. ----- ## Data Contracts Orgo enforces strict JSON schemas for its primary objects to ensure interoperability between modules. **The Case Contract (Simplified):** ```jsonc { "case_id": "uuid", "label": "1001.91.Operations.Safety", "status": "open", "severity": "high", "reactivity_time": "PT1H", // ISO 8601 Duration "origin_role": "Operations.Safety", "location": { "site": "Main", "area": "Lobby" }, "metadata": { "incident_type": "slip_fall" } } ```` **The Task Contract (Simplified):** ```jsonc { "task_id": "uuid", "case_id": "uuid", "type": "maintenance", // Domain "subtype": "cleaning", // Specifics "status": "pending", "owner_role_id": "uuid", // Who is responsible "due_at": "2025-12-12T14:00:00Z" } ``` ----- ## Cyclic Review System Orgo is not just for "doing work"; it is for **improving operations**. The system enforces a **Cyclic Overview** process driven by the Insights module. 1. **Weekly Loop:** Review all `critical` and `unresolved` items. Immediate tactical fixes. 2. **Monthly Loop:** Review trends by Department and Location. Detect resource imbalances. 3. **Yearly Loop:** Strategic review. Input for next year's Profile configuration. **Pattern Detection:** The engine can be configured to auto-escalate "soft signals." For example: *"If 5 tasks of subtype 'leak' occur in 'Building A' within 30 days, auto-create a Case titled 'Infrastructure Audit: Building A'."* ----- ## Status and Scope **What Orgo IS:** * A unified Case & Task routing platform. * A pattern detection engine. * A structured communication tool using Wikidata standards (via SenTient) for interoperability. * A **Hermetic** system capable of total offline autonomy. **What Orgo is NOT:** * An ERP (It does not do payroll or inventory accounting). * A Chat App (It is for structured work, not casual conversation). * A Kanban Toy (It enforces rigorous routing rules). ================================================================================================ FILE: Rejean-en/SenTient/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: bf94c47b9d0a9165856c776e8b34cfc0fd4e94560d6db841e35a3e70842cf66e CONTENT_BYTES: 8050 ================================================================================================ ## SenTient (Semantic Entity Intelligent Transformation) **Version:** 1.0.0-RC2 **Status:** Production Ready (Hybrid Architecture) --- ## 1. Executive Summary and Core Philosophy **SenTient** is a next-generation Entity Reconciliation and Relation Extraction engine designed to bridge the gap between messy, unstructured text and structured Knowledge Graphs (Wikidata/Wikibase). The core philosophy is a **Hybrid Orchestration System** that combines three distinct technological lineages into a single "Funnel" pipeline to achieve high performance and accuracy: * **Speed (Layer 1):** The FST-based rapid tagging of **OpenTapioca** (Solr). * **Semantics (Layer 2):** The context-aware NLP of **Falcon 2.0** (Python/SBERT/Elastic). * **Structure (Layer 3):** The robust data modeling and state management of **OpenRefine** (Java Core + DuckDB). ### Key Architectural Features * **Performance Target:** High Precision ($>0.85$) and High Recall ($>0.80$) while maintaining a sub-second response time for user interactivity. * **Hybrid Memory Architecture:** The Java Core uses a split-state strategy, keeping lightweight status flags and Row IDs in **Hot RAM** for instant faceting, while offloading heavy AI payloads (vectors, candidates, scores) to a **DuckDB Sidecar** (Cold Data). This approach supports datasets exceeding 5GB. * **Decoupled Frontend:** The UI (React/Vite on Port `3000`) is decoupled from the Java Core (Jetty on Port `3333`) and communicates via a REST-like Command Pattern API. --- ## 2. The Three-Layer Funnel and Processing Pipeline The system operates on a "Funnel" logic: broad and fast at the top, narrow and precise at the bottom. The unit of work is the **SmartCell** object, which acts as the immutable contract across all layers. ### 2.1. Layer 1: Ingestion & Fast Tagging (The Sieve) * **Component:** `index_solr` + `core_java (Clustering)`. * **Role:** High-speed identification of "Surface Forms" using string matching and pre-calculated popularity. * **Latency Budget:** Must be **< 50ms per batch**. * **Process Flow:** 1. **Normalization & Fingerprinting:** Java performs client-side deduplication using the **Key Collision Fingerprint** algorithm (tokenize, clean, sort, join) to minimize Solr API calls. 2. **FST Tagger:** The normalized text is passed to the **Solr TaggerHandler**, which uses a memory-mapped **Finite State Transducer (FST)** containing $\approx 14M$ Wikidata items. Lookup time is $O(k)$. 3. **Authority Filter:** Candidates with low `popularity_score` ($< 100$) or those matching stop words are immediately pruned. ### 2.2. Layer 2: The Semantic Linguist (Falcon 2.0) * **Component:** `nlp_falcon` (Python 3.9+, Flask, SBERT). * **Role:** Contextual disambiguation (solving the "Paris Problem") and semantic analysis. * **Latency Budget:** $\approx 200ms$ per entity batch (Target). * **Process Flow:** 1. **Preprocessing:** **Falcon Optimization** uses stopword pruning (`falcon_extended_en.txt`) and N-Gram generation to clean the signal. 2. **Property Extraction (Edge Detector):** Queries the `sentient_properties_v1` ElasticSearch index to infer the most likely **Wikidata Property (Predicate)**, boosting or penalizing entity candidates accordingly. 3. **Vector Scoring:** Encodes the 5-word context window into a 768-dimensional vector using **SBERT** (`all-MiniLM-L6-v2`). It then calculates **Cosine Similarity** ($S_{\text{Context}}$) between the input vector and candidate description vectors fetched from the `sentient_entities_fallback` Elastic index. ### 2.3. Layer 3: The Core Orchestrator (Final Adjudication) * **Component:** `core_java` (Java 17, Jetty 10, Butterfly Framework). * **Role:** Final Adjudication, Asynchronous Process Management, and State Serialization. * **Process Flow:** 1. **Async Management:** Frontend triggers a **Command** (`ReconcileCommand`), which launches a non-blocking `LongRunningProcess` managed by the `ProcessManager` (utilizing a `ThreadPoolExecutorAdapter`). The Frontend polls for progress. 2. **Consensus Scoring:** Upon receiving Layer 2 scores, the Core performs **Score Normalization** (using a Sigmoid function with $k=2.0$, $m=3.0$) on Solr's raw $\log_{score}$ to map it to a [0, 1] range. It then applies the final weighted formula: $$\text{Score}_{\text{Sentry}} = (S_{\text{Normalized}} \times 0.4) + (S_{\text{Falcon}} \times 0.3) + (S_{\text{Levenshtein}} \times 0.3) \text{}$$ 3. **Data Offload:** The orchestrator calls `DuckDBStore.insertBatch()` to persist heavy vectors to disk and flags the in-memory **Cell** as `RECONCILED` (lightweight state). 4. **History & Serialization:** Every data modification is a **Transaction** implementing the `AbstractOperation` Command Pattern, ensuring that state can be restored by re-applying the History log upon server crash. --- ## 3. QA, Validation & Benchmarking The QA Strategy relies on three pillars to statistically prove system improvement over time. ### 3.1. The Scrutinizers (Runtime Validation) Scrutinizers are "Linting Rules for Data" located in `config/qa/scrutinizer_rules.yaml`. They run in the Java Core *before* export. * **Integrity Scrutinizers:** Block export if data is logically corrupt (e.g., `MATCHED` cell has a null QID). * **Constraint Scrutinizers:** Check for Wikidata alignment violations (e.g., Single Value Constraint) and show a `WARNING`. * **Consensus Scrutinizers:** Check for statistical anomalies in scores (e.g., "Paris Hilton Rule": high popularity but low context score). ### 3.2. Golden Standard Datasets Accuracy is measured against ground truth using industry-standard datasets: * **LC-QuAD 2.0:** Validating complex relation extraction. * **SimpleQuestions:** Validating simple entity spotting speed (Target Latency $< 50ms$/query). * **WebQSP:** Testing disambiguation of ambiguous surface forms. ### 3.3. Benchmarking & Deployment Guardrail The `evaluate_falcon_api.py` script runs the full pipeline. | Metric | Target (v1.0) | Acceptable Range | | :--- | :--- | :--- | | **Precision** | 0.85 | $> 0.80$ | | **Recall** | 0.82 | $> 0.75$ | | **F-Score** | 0.83 | $> 0.78$ | | **Latency (p95)** | 200ms | $< 500ms$ | **Deployment Rule:** If Precision drops by $> 2\%$ after a model update (e.g., SBERT or Solr FST index), the deployment is **rejected**. --- ## 4. Data Dictionary: The SmartCell Protocol The **SmartCell** is the immutable data contract defined in `schemas/data/smart_cell.json`. | Logical Field | JSON Type | Java Type | Python Type | Description | | :--- | :--- | :--- | :--- | :--- | | `raw_value` | `String` | `String` | `str` | Original user input (never modified) | | `status` | `Enum (String)` | `Recon.Judgment` | `str` | Current lifecycle state (`NEW`, `PENDING`, `MATCHED`, etc.) | | `consensus_score` | `Float` | `float` (transient) | `float` | Final calculated confidence (0.0 to 1.0) | | `match` | `Candidate` Obj | `ReconCandidate` | `dict` | The single winning entity (if reconciled) | | `vector` | `Array` | `double[]` | `np.ndarray` | SBERT embedding payload | ### Telemetry (`features`) The `Candidate` object contains a `features` object used for UI visualization and debugging. The Frontend renders a stacked bar chart based on these weights: * `tapioca_popularity` (Solr Log-Likelihood). * `falcon_context` (Cosine Similarity from SBERT). * `levenshtein_distance` (Normalized string distance from Java Core). --- ## 5. Wiring & Configuration Strategy ### Network Topology (Port Map) All services are bound strictly to `127.0.0.1` for security. | Service | Port | Protocol | Timeout | | :--- | :--- | :--- | :--- | | **Java Core (Orchestrator)** | `3333` | HTTP/1.1 | - | | **Falcon (Python)** | `5005` | HTTP/1.1 | 120s (Throttled) | | **Solr (Tapioca)** | `8983` | HTTP/2 | 500ms (Strict) | | **ElasticSearch** | `9200` | HTTP/TCP | - | ### File System Layout The central configuration files are located in `config/orchestration/environment.json` and other files within the `config/` directory. ================================================================================================ FILE: Rejean-en/SwarmCraft/Core/Architecture-Overview.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 55aacf8e86f4f064bcc1e13d1d7e1129a8a6098b0d3ee04b058c27305cdfd04c CONTENT_BYTES: 5799 ================================================================================================ # Architecture Overview > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** SwarmCraft is a **deterministic, data-driven story engine**. It transforms explicit project state into prose using a strict control loop and a layered architecture that separates: - **Brain** (LLM personas and prompt behaviors) - **Logic** (orchestration, tools, validation) - **Memory** (project state files + RAG index) --- ## 1) The Three-Layer Model (Brain / Logic / Memory) ### Brain (LLM Personas) Stateless services that generate or evaluate content. They never own canonical state. Typical personas: - **Architect**: plans next actions and targets - **Narrator**: drafts/revises prose for one Part - **Editor**: validates prose against scaffold + continuity Location (typical): - `ai_services/` ### Logic (Deterministic Engine) The orchestrated runtime that: - selects what to do next - hydrates prompts slice-by-slice - executes file operations through guarded tools - enforces the update cycle Core modules (typical): - `core/orchestrator.py` - `core/agent_tools.py` - `core/project_manager.py` - `core/scanner.py` (or equivalent) ### Memory (Explicit Project State) All durable “truth” lives in versionable state and indexes: - **Matrix** (runtime state): `data/matrix.json` - **Story Bible** (creative intent): `data/story_bible/` - **RAG memory DB** (long-term continuity): `data/memory_db/` (per project) --- ## 2) The Deterministic Control Loop SwarmCraft runs a strict cycle: **SCAN → PLAN → EXECUTE** - **SCAN** Reads filesystem + state, updates Matrix metrics/status, ingests new prose into RAG memory. - **PLAN** Architect selects the next target **Part** and action (draft/revise/review), based on Matrix status + control signals. - **EXECUTE** Narrator/Editor runs for exactly one Part. All mutations occur via tools, then the system returns to SCAN. Details: **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** --- ## 3) Core Data Objects ### 3.1 Matrix (Runtime State) `data/matrix.json` is the machine-readable view of “what exists and what’s next.” It tracks: - per-part manuscript path - status (`EMPTY`, `DRAFTING`, `REVIEW_READY`, `REVISION_NEEDED`, `LOCKED`) - active task target (always a **Part**) - word counts, timestamps, metrics Details: **[Central Matrix](Central-Matrix-Runtime-State.md)** ### 3.2 Story Bible (Creative Intent) The Story Bible stores the canonical creative plan: - characters, lore, constraints, style rules - **templates** and **outline** (the Story Scaffold) Details: **[Story Bible](Story-Bible-Creative-Intent.md)** ### 3.3 Story Scaffold (Templates + Outline + Parts) The scaffold is the structured narrative “grid” that humans and the Wizard can edit: - **Templates** define: - thread set (Plot, Character Development, etc.) - cadence rules (how often threads must be filled) - default parts-per-chapter (and allowed bounds) - **Outline** defines: - chapters → parts mapping - per-part thread beats (grid cells) - per-part contract (goal / obstacle / turn / outcome) - locks (protect manual edits) Details: - **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** - **[Schema: Templates](Schema: Templates.md)** - **[Schema: Outline](Schema: Outline.md)** - **[Outline Grid & CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** --- ## 4) Units of Work: Parts, Not Chapters A **Part** is the atomic unit SwarmCraft drafts and revises. - A chapter may contain **1–6 parts** depending on template and user choice. - Parts enable: - small, stable prompt slices - targeted regeneration (one beat / one part) - better continuity control - clearer status tracking Part orchestration: **[Orchestration: Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** --- ## 5) Multi-Project Isolation SwarmCraft supports multiple isolated projects (universes): - each project has its own: - `matrix.json` - `story_bible/` - `memory_db/` Details: **[Multi-Project Management](Multi-Project-Management.md)** --- ## 6) RAG Memory for Long-Form Continuity The memory system ingests written prose and enables semantic retrieval: - prevents character/world drift - reduces plot holes - avoids bloating prompts with “story so far” Details: **[RAG Memory System](RAG-Memory-System.md)** --- ## 7) Control Surfaces SwarmCraft is designed to be observable and steerable: - **TUI Dashboard**: real-time view of tasks, logs, and state Details: **[Dashboard Reference](Dashboard-TUI-Reference.md)** - **Control file** (implementation-specific): pause/resume/override planning without coupling UI to engine. --- ## 8) Provider Integration (Grok) SwarmCraft uses a provider adapter to keep the engine model-agnostic: - normalizes tool calling and responses - centralizes API settings and error handling - enables “Powered by Grok” without hardwiring provider logic everywhere Details: **[Provider Adapter: Grok](Provider-Adapter-Grok.md)** --- ## 9) Where to Go Next - **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** - **[Central Matrix](Central-Matrix-Runtime-State.md)** - **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** - **[Orchestration: Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Core/Central-Matrix-Runtime-State.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: f4ecead285c5c0a252d1c3a2f63a3f8a158a62697d77a3416edd404387ee9e14 CONTENT_BYTES: 5698 ================================================================================================ # Story Bible (Creative Intent) > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** The **Story Bible** is SwarmCraft’s home for **creative intent**: the canonical narrative plan, constraints, and reference material that guide drafting and revision. It is designed to be: - **explicit** (no hidden “chat history” requirements) - **versionable** (text/JSON files under source control) - **sliceable** (only the relevant subset is injected into prompts) - **human-editable** (writers can edit directly or through UI) The Story Bible is distinct from: - **Matrix** (runtime progress state): **[Central Matrix](Central-Matrix-Runtime-State.md)** - **RAG memory** (retrieved continuity evidence): **[RAG Memory System](RAG-Memory-System.md)** --- ## 1) Location and Project Isolation **Recommended per-project location:** - `projects//data/story_bible/` Single-project setups MAY use: - `data/story_bible/` The Story Bible is project-scoped. Each project has its own Bible and must not share it implicitly. See: **[Multi-Project Management](Multi-Project-Management.md)** --- ## 2) What Lives in the Story Bible SwarmCraft treats the Story Bible as the canonical source for: ### 2.1 Canonical references - Characters (bios, arcs, secrets, voice constraints) - Locations (maps, rules, sensory signatures) - Lore (history, factions, magic/tech rules) - Style rules (tone, POV, reading level, taboo list) - Constraints (hard rules the Editor enforces) These may be stored in Markdown or JSON, depending on preference and tooling. ### 2.2 The Story Scaffold (New) The scaffold is part of the Story Bible because it is **creative intent**, not runtime state: - **Templates:** `templates/.json` Defines threads (Plot, Character Development, etc.), cadence expectations, and default parts/chapter. - **Outline:** `outline.json` Defines chapters → parts mapping, per-part thread beats, and per-part “contract”. Scaffold entry point: - **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** --- ## 3) Recommended Folder Layout Example: ```text projects//data/story_bible/ ├── README.md ├── outline.json ├── templates/ │ ├── children.picturebook.json │ ├── novel.default.json │ └── screenplay.default.json ├── characters/ │ ├── king_klown.md │ └── ... ├── locations/ │ ├── cosmic_council_hall.md │ └── ... ├── lore/ │ ├── world_rules.md │ └── ... ├── constraints/ │ ├── hard_rules.md │ └── style_guide.md └── glossaries/ └── terms.md ```` This is a recommendation, not a constraint—projects may reorganize, but the engine must be able to find `outline.json` and the selected `templates/.json`. --- ## 4) Bible vs Matrix vs Memory (Key Separation) ### Story Bible (Intent) * “What the story *should be*.” * Edited by humans and the Wizard. * Used as authoritative instruction. ### Matrix (Runtime) * “What the system has *done* and what is next.” * Derived from disk and updated by tools. * Tracks statuses and active tasks. See: **[Central Matrix](Central-Matrix-Runtime-State.md)** ### RAG Memory (Evidence) * “What has been *written before*.” * Queried to prevent continuity drift. * Does not define intent; it provides recall. See: **[RAG Memory System](RAG-Memory-System.md)** --- ## 5) How the Bible Is Used in Prompts (Slice-by-Slice) SwarmCraft never dumps the whole Story Bible into the LLM. Instead, the orchestrator hydrates prompts by selecting only: * the target Part’s beats + contract from the Outline * the minimal character/location/lore references required for that Part * applicable constraints (style/voice/safety rules) This reduces repetition, keeps cost stable, and prevents “prompt sprawl.” See: **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** --- ## 6) Editing Workflows The Story Bible supports three editing modes: 1. **Wizard-generated scaffold** A guided LLM workflow creates the first template selection + outline draft. 2. **Grid editing (human-friendly)** Outline beats are displayed as a grid (threads × parts), with optional CSV round-trip. 3. **Direct file edits** Writers can edit Markdown/JSON files directly, then SCAN reconciles changes. Grid + CSV: * **[Outline Grid CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** --- ## 7) Integrity Rules (Recommended) The scanner/orchestrator SHOULD validate: * the chosen template thread list matches the outline beats keys * every Part referenced in outline has a stable `part_id` * locks are honored (beats/contract/manuscript) * no orphan manuscripts exist without a Part mapping (or they are flagged) --- ## 8) Related Pages * **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** * **[Schema Templates](Schema-Templates.md)** * **[Schema Outline](Schema-Outline.md)** * **[Outline Grid CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** * **[Central Matrix](Central-Matrix-Runtime-State.md)** * **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Core/Deterministic-Pipeline-Scan-Plan-Execute.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 0161b558aaa965595e717a72cf13193a438d0b04175c8fde59210f354a7b9c58 CONTENT_BYTES: 6542 ================================================================================================ # Deterministic Pipeline (SCAN-PLAN-EXECUTE) > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** SwarmCraft runs a strict, repeatable control loop that transforms explicit project state into prose: **SCAN → PLAN → EXECUTE** This loop is designed to be: - deterministic (same state → same next decision at the orchestration layer) - restart-safe (crashes recover by re-scanning truth from disk) - observable (each step is logged; state files are inspectable) --- ## 0) Glossary - **Part**: the atomic unit of drafting/revision. Chapters are rollups over Parts. - **Matrix**: runtime state (`data/matrix.json`). - **Story Bible**: creative intent (`data/story_bible/`). - **Scaffold**: templates + outline (parts mapping + thread beats + contracts). --- ## 1) Cycle Overview ### 1.1 SCAN Recompute reality from disk and refresh runtime state. Outputs: - refreshed `data/matrix.json` - optional RAG ingestion updates (per project) ### 1.2 PLAN Select one target Part and one action. Outputs: - `matrix.active_task` populated with `{ target_id, action, reason }` - optional “narrow queries” requested for continuity ### 1.3 EXECUTE Run one persona on one Part, then persist results via tools. Outputs: - updated manuscript file for the Part, or review notes - updated matrix bookkeeping - return to SCAN --- ## 2) SCAN (Normative) ### 2.1 Inputs SCAN reads: - `data/story_bible/outline.json` (Parts ordering + locks) - `data/story_bible/templates/.json` (thread set + cadence) - manuscripts under `data/manuscripts/` (or configured root) - existing `data/matrix.json` - `data/memory_db/` (if RAG enabled) ### 2.2 Responsibilities SCAN MUST: 1. Enumerate expected **Parts** from `outline.json`. 2. Verify presence of each Part’s manuscript file. 3. Compute per-part metrics: - word count - last modified time - status 4. Respect locks: - never downgrade a `LOCKED` part - never infer unlocks automatically 5. Validate integrity: - missing parts - missing beats keys (fill with empty strings in UI projection) - schema mismatch between template threads and outline beats 6. Optionally ingest changed prose into RAG memory. 7. Atomically write the updated `data/matrix.json`. ### 2.3 Status derivation (Recommended) A scanner SHOULD classify a Part as: - `EMPTY`: file missing or below minimum threshold - `DRAFTING`: draft exists but incomplete - `REVIEW_READY`: draft is complete enough for Editor pass - `REVISION_NEEDED`: flagged by Editor or override - `LOCKED`: protected from further automated edits Matrix semantics: **[Central Matrix](Central-Matrix-Runtime-State.md)** --- ## 3) PLAN (Normative) ### 3.1 Inputs PLAN reads: - current `data/matrix.json` - `outline.json` for ordering + locks - operator overrides (control surface), if present ### 3.2 Selection policy (Recommended default) Absent overrides, the Architect SHOULD prioritize: 1. Any Part with `REVISION_NEEDED` 2. The earliest Part with `EMPTY` 3. The earliest Part with `DRAFTING` 4. Optional: any Part failing integrity checks (continuity, constraints, missing sections) ### 3.3 Hard constraints PLAN MUST NOT select: - Matrix `LOCKED` Parts - Parts whose Outline locks prohibit changes (mapping depends on implementation: beats vs contract vs manuscript) ### 3.4 Plan output shape The plan MUST specify: - `target_type: "part"` - `target_id: ""` - `action: "DRAFT" | "REVISE" | "REVIEW"` - optional: `priority`, `reason`, `requested_memory_queries[]` The orchestrator persists the plan into `matrix.active_task`. --- ## 4) EXECUTE (Normative) EXECUTE performs exactly one scoped operation on exactly one Part. ### 4.1 Prompt hydration (Part slice) Before invoking a persona, the orchestrator MUST hydrate a **Part slice**: - the target Part’s thread beats (cells) - the Part contract (goal/obstacle/turn/outcome) - minimal continuity: - previous Part outcome summary (or last approved beat summary) - chapter-level goal/summary (if defined in outline) - relevant character/lore snippets (only what’s needed) - project-level style constraints Details: **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** ### 4.2 Narrator execution (DRAFT / REVISE) If action is `DRAFT` or `REVISE`: - the Narrator produces prose for exactly one Part - prose is written to `data/manuscripts/.md` (recommended) - the orchestrator updates Matrix bookkeeping and returns to SCAN ### 4.3 Editor execution (REVIEW) If action is `REVIEW`: - the Editor checks the manuscript against: - Part beats + contract - continuity constraints (optionally via RAG) - style constraints - output is either: - approve (advance to `REVIEW_READY` / candidate for locking), or - revision request (set `REVISION_NEEDED` with structured notes) ### 4.4 Tool safety All modifications MUST go through the guarded tool layer (file ops + state updates). No persona may mutate project files directly. --- ## 5) Atomicity, Concurrency, and Restart Safety ### 5.1 Atomic step rule One loop iteration = one atomic action: - one SCAN refresh - one PLAN decision - one EXECUTE action on one Part ### 5.2 No concurrent writers Only one worker persona may write at a time for the active project. ### 5.3 Crash recovery On restart: - SCAN re-derives truth from disk - Matrix is reconciled (locks respected) - execution resumes without reliance on chat history --- ## 6) Observability and Control - Dashboard observes `matrix.json`, logs, and metrics without blocking the engine. - Control signals/overrides may affect PLAN (target selection) without breaking the deterministic loop. Dashboard: **[Dashboard TUI Reference](Dashboard-TUI-Reference.md)** --- ## 7) Related Pages - **[Architecture Overview](Architecture-Overview.md)** - **[Central Matrix](Central-Matrix-Runtime-State.md)** - **[Story Bible](Story-Bible-Creative-Intent.md)** - **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** - **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ffeef49d63e4526ed5ecf61af856a6cd3157305e2362f7ba347995d159054021 CONTENT_BYTES: 3798 ================================================================================================ # SwarmCraft: Deterministic Story Engine > **Architectural Lineage:** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in `mojomast/swarmussy`. Its deterministic layering is derived from the meta-structure of the **Abstract Wiki Architect**. ## **POWERED BY GROK** **SwarmCraft** is a deterministic, data-driven story engine designed to transform explicit project state into prose using a strict control loop. Unlike chat-based swarms, it separates **Brain** (LLM personas), **Logic** (orchestration), and **Memory** (explicit state) to ensure long-form narrative coherence. --- ## 1. Core Architecture The system operates on a **"Three-Layer Model"** to prevent hallucinations and state drift: * **Brain (Personas):** Stateless services (Architect, Narrator, Editor) that never own canonical state. * **Logic (Engine):** The runtime that handles the `SCAN → PLAN → EXECUTE` loop and tool execution. * **Memory (State):** All truth lives in the **Matrix** (runtime status), **Story Bible** (creative intent), and **RAG DB** (long-term continuity). ### The Deterministic Pipeline SwarmCraft replaces emergent coordination with a strict cycle: 1. **SCAN:** Recompute reality from disk. 2. **PLAN:** Select the next atomic **Part** to draft or revise. 3. **EXECUTE:** Run one persona on that Part, then exit. --- ## 2. Documentation Modules ### Core Logic & Orchestration * [**Architecture Overview**](Core/Architecture-Overview.md) – High-level diagram of the Brain/Logic/Memory separation. * [**Deterministic Pipeline**](Core/Deterministic-Pipeline-Scan-Plan-Execute.md) – Detailed breakdown of the SCAN-PLAN-EXECUTE control loop. * [**Prompt Hydration**](Runtime/Orchestration-Slice-By-Slice-Prompt-Hydration.md) – How the engine prevents "prompt sprawl" by injecting only the active Part slice. * [**Provider Adapter: Grok**](Runtime/Provider-Adapter-Grok.md) – The normalization layer that keeps the engine model-agnostic. ### State & Schema (The Truth) * [**Central Matrix**](Core/Central-Matrix-Runtime-State.md) – The machine-readable runtime state (`matrix.json`). * [**Story Bible (Intent)**](Scaffold/Story-Bible-Creative-Intent.md) – Where characters, lore, and constraints live. * [**Story Scaffold**](Scaffold/Story-Scaffold-Templates-Outline-Parts.md) – The grid system combining Templates and Outlines. * [**Schema: Templates**](Scaffold/Schema-Templates.md) – Defining thread sets and pacing rules. * [**Schema: Outline**](Scaffold/Schema-Outline.md) – Defining chapters, parts, and beat contracts. ### Operations & Usage * [**Dashboard TUI**](Runtime/Dashboard-TUI-Reference.md) – The "Mission Control" interface for observing the engine. * [**Multi-Project Management**](Runtime/Multi-Project-Management.md) – Running isolated universes in a single runtime. * [**Outline Grid & CSV**](Scaffold/Outline-Grid-CSV-Round-Trip.md) – Round-tripping the story structure via spreadsheets. * [**RAG Memory System**](Runtime/RAG-Memory-System.md) – Long-term retrieval for narrative continuity. --- ## 3. Key Concepts ### Parts, Not Chapters The atomic unit of work is the **Part**. Chapters are simply rollups of 1–6 Parts. This allows for small, stable prompt slices and targeted regeneration. ### Slice-by-Slice Hydration The engine never dumps the whole Story Bible into the LLM. It hydrates prompts with **only** the active Part's beats, contract, and relevant RAG evidence. ### Credits & Lineage * **Upstream Foundation:** Mojomast/swarmussy (Multi-agent patterns, TUI concepts). * **Meta-Structure:** Abstract Wiki Architect (State separation). * **Full Credits:** [**Read the Credits & Lineage Page**](Meta/Credits-And-Lineage.md). ================================================================================================ FILE: Rejean-en/SwarmCraft/Meta/Credits-And-Lineage.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: ae9494abb58130933b23336771e492987729bfd679aac4773fa16ae4e098a8f3 CONTENT_BYTES: 4438 ================================================================================================ # Credits & Lineage SwarmCraft is built on two explicit lineages: 1) **Swarm foundation (upstream):** the multi-agent swarm engine patterns created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. 2) **Architect meta-structure (AWA):** the deterministic “Architect-style” separation of **Brain / Logic / Memory** and state-first orchestration derived from **Abstract Wiki Architect (AWA)**. --- ## 1) Upstream Credit: Mojomast / swarmussy SwarmCraft is an **architectural fork and deep rewrite**. The upstream project established the original swarm runtime approach and core implementation patterns. **All architectural credit** for the original **multi-agent swarm design**—including the chatroom runtime concepts, terminal dashboard pattern, and foundational orchestration/tooling modules—belongs to **Mojomast**: - Upstream author: **[Mojomast](https://github.com/mojomast)** - Upstream repository: **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)** ### Upstream-derived core module lineage (examples) SwarmCraft acknowledges lineage (conceptual and/or code-derived depending on file history) from swarmussy patterns around: - Agent tooling gateway - `core/agent_tools.py` - Task planning / task routing - `core/task_manager.py` - Token usage tracking - `core/token_tracker.py` - Dashboard / mission control pattern (TUI) If upstream code is present in this repository, upstream license notices must be preserved alongside the derived files. --- ## 2) What SwarmCraft Adds / Changes SwarmCraft reuses and extends the swarm foundation while introducing deterministic, story-first architecture and structured narrative state. ### 2.1 Deterministic pipeline SwarmCraft replaces chatroom-style emergent coordination with a strict loop: **SCAN → PLAN → EXECUTE** - SCAN: reconcile truth from disk and update runtime state - PLAN: select the next target Part and action - EXECUTE: run one persona on one Part using guarded tools See: **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** ### 2.2 State-first narrative architecture (Brain / Logic / Memory) SwarmCraft formalizes narrative work into explicit layers: - **Brain**: stateless LLM personas (Architect, Narrator, Editor) - **Logic**: orchestrator + tools + validation - **Memory**: Matrix + Story Bible + RAG index See: **[Architecture Overview](Architecture-Overview.md)** ### 2.3 Parts-based story execution SwarmCraft treats a **Part** as the atomic unit of drafting/revision. Chapters are rollups over Parts. See: - **[Central Matrix](Central-Matrix-Runtime-State.md)** - **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** ### 2.4 Story Scaffold (Templates + Outline + Grid) SwarmCraft introduces a structured story scaffold designed for both humans and LLMs: - Templates define threads + cadence + default parts/chapter - Outline defines chapters→parts mapping + per-part thread beats + part contracts - Grid view displays the outline as a spreadsheet-like matrix, with optional CSV round-trip See: - **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** - **[Schema Templates](Schema-Templates.md)** - **[Schema Outline](Schema-Outline.md)** - **[Outline Grid CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** ### 2.5 Multi-project isolation Each project has isolated: - Matrix - Story Bible - Memory DB (RAG) See: **[Multi-Project Management](Multi-Project-Management.md)** ### 2.6 RAG long-term continuity SwarmCraft integrates per-project retrieval memory to maintain coherence in long works. See: **[RAG Memory System](RAG-Memory-System.md)** --- ## 3) Provider Layer (Powered by Grok) SwarmCraft is **powered by Grok** via a provider adapter that keeps the engine provider-agnostic: - normalized request/response - normalized tool calling - centralized retries and error handling See: **[Provider Adapter Grok](Provider-Adapter-Grok.md)** --- ## 4) Attribution Guidance for Derivative Works If you build on SwarmCraft, you should preserve: - this Credits & Lineage page (or an equivalent notice in your primary documentation) - upstream references to Mojomast/swarmussy - any third-party license notices for code you redistribute This page is the canonical place for lineage statements to avoid repeating long credit blocks throughout the wiki. ================================================================================================ FILE: Rejean-en/SwarmCraft/Runtime/Dashboard-TUI-Reference.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: fe870c8db99c366f56c5a838013ff68756593ccd578feef91d55b805e80f12dc CONTENT_BYTES: 4938 ================================================================================================ # Dashboard TUI Reference > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > The dashboard pattern is also downstream of Mojomast’s original “mission control” approach for observing swarm activity. > SwarmCraft’s deterministic layering is derived from the meta-structure of **Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** The SwarmCraft Dashboard is a **Terminal UI (TUI)** that observes and steers the engine while keeping UI and execution decoupled. Key principle: - **Engine runs the AI work** - **Dashboard renders state and sends control signals** This prevents UI freezes and supports restart-safe operation. --- ## 1) What the Dashboard Watches The dashboard should primarily read: - `data/matrix.json` (runtime state) - `data/story_bible/outline.json` (structure reference, optional) - logs (engine logs, tool logs) - token usage metrics (if tracked) The dashboard must never be the source of truth; it is a view/controller. Matrix reference: **[Central Matrix](Central-Matrix-Runtime-State.md)** --- ## 2) Recommended Layout (3-Column Mission Control) A recommended high-level layout: ### 2.1 Context Panel (Left) Shows “what the engine is currently focused on”: - active project (project_id) - active chapter + part (from `matrix.active_task`) - cast in scope (optional, derived from outline or tags) - location in scope (optional) - active tool (what the engine is doing right now) ### 2.2 Action Panel (Center) Shows “what is happening”: - prose stream (latest generated text excerpt) - system log tail (planner decisions, tool calls, warnings/errors) - current step indicator (SCAN / PLAN / EXECUTE) ### 2.3 Progress Panel (Right) Shows “how the project is doing”: - parts table (status, locks, word counts) - chapter rollups (optional) - integrity signals (missing files, schema drift) - cost/tokens counters --- ## 3) Core Widgets (Recommended) ### 3.1 Active Task Card Displays: - `target_type` (should be `part`) - `target_id` (Part ID) - action (`DRAFT`, `REVISE`, `REVIEW`) - reason (planner rationale) - elapsed time ### 3.2 Matrix Table Backed by `matrix.parts`: - Part ID - Chapter ID - Status (`EMPTY`, `DRAFTING`, `REVIEW_READY`, `REVISION_NEEDED`, `LOCKED`) - Locked indicator - Word count - Last modified ### 3.3 Integrity / Alerts Derived from scan validation: - missing manuscripts - outline/template mismatch (thread keys) - orphan manuscripts - locked conflicts ### 3.4 Token / Cost Tracker (Optional) If token tracking is enabled: - tokens in / out per step - per-session totals - optional cost estimate --- ## 4) Control Surface (Director Override) The dashboard may write control signals to a project-scoped control file, e.g.: - `projects//data/control.json` Typical fields (recommended): ```json { "run_state": "RUNNING", "architect_override": { "force_target_part_id": null, "force_action": null, "note": null } } ```` ### 4.1 Run states * `RUNNING` * `PAUSED` * `STOPPED` ### 4.2 Override behaviors (Recommended) Overrides should be applied at PLAN-time: * force focus on a specific part * force a specific action (review vs revise) * inject a short director note that becomes part of the plan rationale The deterministic loop remains intact: * overrides influence selection, not execution ordering Pipeline: **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** --- ## 5) Multi-Project UX If multiple projects exist, dashboard SHOULD display: * active project id * quick switch mechanism (implementation dependent) * project health summary Multi-project: **[Multi-Project Management](Multi-Project-Management.md)** --- ## 6) Failure and Recovery UX The dashboard should handle: * engine crash (dashboard stays up) * engine restart (dashboard reconnects to state files) * partial writes (prefer atomic writes in engine) Recommended indicators: * “Engine heartbeat” or “last update timestamp” from Matrix * last SCAN time * last EXECUTE time Matrix includes timestamps: **[Central Matrix](Central-Matrix-Runtime-State.md)** --- ## 7) What the Dashboard Should Not Do * It should not run LLM calls. * It should not mutate manuscripts directly. * It should not edit Story Bible files directly unless explicitly a dedicated editor UI (separate feature). All modifications should go through the engine tools layer. --- ## 8) Related Pages * **[Central Matrix](Central-Matrix-Runtime-State.md)** * **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** * **[Story Bible](Story-Bible-Creative-Intent.md)** * **[Multi-Project Management](Multi-Project-Management.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Runtime/Multi-Project-Management.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 5b39ec48eb378a4984c1263e111942671369503ff06381dfb636f95c5c51a1e5 CONTENT_BYTES: 4283 ================================================================================================ # Multi-Project Management > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** SwarmCraft supports multiple isolated projects (“universes”) in the same repository/runtime. A **project** is an isolated unit that contains: - its own Story Bible (templates + outline + references) - its own Central Matrix (runtime state) - its own RAG Memory DB - its own manuscripts and logs (recommended) This prevents cross-story contamination and enables switching between worlds without restarting the whole engine. --- ## 1) Project Root Structure (Recommended) SwarmCraft SHOULD use a `projects/` root: ```text root/ └── projects/ ├── .last_project │ ├── project_alpha/ │ └── data/ │ ├── matrix.json │ ├── story_bible/ │ │ ├── outline.json │ │ └── templates/ │ ├── memory_db/ │ └── manuscripts/ │ └── project_beta/ └── data/ ├── matrix.json ├── story_bible/ ├── memory_db/ └── manuscripts/ ```` Notes: * `projects//data/` is the canonical project data root. * Manuscripts under `data/manuscripts/` is recommended to keep everything portable. --- ## 2) Project Identity Each project is identified by its folder name: * `project_id = "project_alpha"` The project ID should be: * stable (do not rename casually) * filesystem-safe (ASCII, no spaces recommended) --- ## 3) What Isolated Means (Normative) For correctness, projects MUST NOT share: * `matrix.json` (runtime state) * `story_bible/` (creative intent) * `memory_db/` (RAG vectors) If your implementation uses global caches, they MUST be keyed by `project_id`. --- ## 4) Switching Projects A project manager component (implementation detail) typically supports: * list available projects * set active project * remember last active project ### 4.1 `.last_project` (Recommended) A simple pointer file: * `projects/.last_project` Contents: ```text project_alpha ``` On startup: * if an explicit project is not chosen, engine loads `.last_project` * if missing, engine may prompt or choose a default (implementation choice) --- ## 5) Per-Project Lifecycle ### 5.1 Create a project (Recommended behavior) Creating a project should: 1. Create `projects//data/` 2. Create an initial Story Bible structure: * `story_bible/templates/` * `story_bible/outline.json` (blank scaffold) 3. Initialize `matrix.json` (empty/initial state) 4. Initialize `memory_db/` (empty DB folder) 5. Optionally create `manuscripts/` folder ### 5.2 Delete a project (Recommended behavior) Deletion should be explicit and guarded. Recommended to require a confirmation flag. --- ## 6) How Multi-Project Interacts with the Pipeline In the deterministic loop, the orchestrator operates against exactly one active project: * SCAN reads/writes `projects//data/*` * PLAN selects the next Part within that project * EXECUTE writes manuscripts and updates Matrix within that project * RAG ingestion/retrieval is scoped to that project’s `memory_db/` Pipeline: **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** --- ## 7) Dashboard Considerations The dashboard should clearly display: * active project ID * active part/chapter target * per-project token usage (session + optional totals) * health/integrity signals for that project only Dashboard: **[Dashboard TUI Reference](Dashboard-TUI-Reference.md)** --- ## 8) Related Pages * **[Central Matrix](Central-Matrix-Runtime-State.md)** * **[Story Bible](Story-Bible-Creative-Intent.md)** * **[RAG Memory System](RAG-Memory-System.md)** * **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Runtime/Orchestration-Slice-By-Slice-Prompt-Hydration.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: f6dd6d7bbe46f47493c088b5f122031422f891ffa7f5aba8ae210e2f9121eac1 CONTENT_BYTES: 6496 ================================================================================================ # Orchestration Slice-by-Slice Prompt Hydration > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** SwarmCraft avoids “prompt sprawl” by hydrating prompts with **only the active slice of the story**. **Slice-by-slice prompt hydration** means: - the engine targets **one Part** - it injects only the **beats + contract** for that Part - it adds only the **minimum continuity** required to write that Part correctly - it runs **one persona** for **one atomic action** - it returns to SCAN This is the core mechanism that prevents scaffold repetition from becoming prose repetition. --- ## 1) Inputs to Prompt Hydration Hydration assembles a prompt from four categories: 1. **Part slice (required)** - the target Part’s thread beats (grid cells) - the target Part’s contract (goal/obstacle/turn/outcome) 2. **Local continuity (required, minimal)** - previous Part outcome (or last approved summary) - chapter summary / chapter objective (if available) - any hard constraints that apply to this moment (POV/tense/reading level) 3. **Global references (optional, clipped)** - character snippets relevant to the scene - location/lore snippets relevant to the scene 4. **Memory retrieval (optional, bounded)** - top-k RAG snippets relevant to this Part’s contract/beat queries Related sources: - Outline: **[Schema Outline](Schema-Outline.md)** - Template threads/cadence: **[Schema Templates](Schema-Templates.md)** - RAG: **[RAG Memory System](RAG-Memory-System.md)** --- ## 2) The Hydration Contract (Normative) The orchestrator MUST obey these constraints: ### 2.1 One Part only Hydration MUST be for exactly one `part_id` at a time. ### 2.2 Minimalism Hydration MUST: - include only beats for the target part - exclude beats for other parts unless explicitly requested as continuity summaries ### 2.3 Bounded memory If RAG is enabled: - retrieval MUST be bounded (top-k, token-limited) - retrieved snippets MUST be formatted as “evidence,” not as new intent ### 2.4 Locks respected If `outline.parts[part_id].locks.manuscript == true`: - orchestrator MUST NOT hydrate a drafting prompt for that part - only review/inspection is allowed (implementation choice) Matrix locking semantics: **[Central Matrix](Central-Matrix-Runtime-State.md)** --- ## 3) Recommended Prompt Structure (Persona-Agnostic) SwarmCraft prompts are assembled in stable sections so they are debuggable and repeatable. Recommended high-level sections: 1. **System / Persona role** 2. **Task definition** 3. **Part contract** 4. **Part beats (thread grid cells)** 5. **Local continuity summary** 6. **Relevant Story Bible excerpts (clipped)** 7. **RAG memory evidence (clipped)** 8. **Output format requirements** --- ## 4) Concrete Hydration Payload (Recommended Shape) This is the structured payload the orchestrator can assemble before rendering a text prompt: ```json { "target": { "chapter_id": "CH01", "part_id": "P001", "action": "DRAFT" }, "contract": { "goal": "...", "obstacle": "...", "turn": "...", "outcome": "..." }, "beats": { "Plot": "...", "Character Development": "...", "Conflict": "...", "Themes": "...", "World-Building": "...", "Emotion": "...", "Symbolism and Imagery": "...", "Structure": "...", "Relationships": "..." }, "continuity": { "previous_part_outcome": "N/A (first part)", "chapter_summary": "Global crisis exposes systemic failure.", "must_preserve": [ "POV: third limited", "Tense: past", "Tone: clear, cinematic" ] }, "references": { "characters": [ {"id": "king_klown", "snippet": "Core traits, current arc state..."} ], "locations": [], "lore": [] }, "rag_evidence": [ {"source": "P000.md", "snippet": "Earlier mention of ..."}, {"source": "king_klown.md", "snippet": "Established constraint ..."} ], "output": { "format": "markdown", "length_target_words": 900, "must_hit_contract": true } } ```` The persona sees a rendered version of this payload, not the entire project. --- ## 5) How the Slice Prevents Repetition Scaffold repetition is acceptable because it is planning data. Prose repetition is not. Hydration prevents repetition by ensuring: * the model is not repeatedly asked to re-summarize all parts * only the current part’s obligations are active * continuity comes in as short “must-preserve” facts and evidence, not as broad story retellings --- ## 6) Editor Hydration (Review Mode) Editor prompts should be even narrower: Include: * part manuscript text (the thing being reviewed) * contract + beats for that part * any “must preserve” constraints * minimal memory evidence (only if needed to verify) Exclude: * beats from other parts * unrelated lore/characters Review outputs SHOULD be structured: * pass/fail per contract field * pass/fail per required thread beat (cadence-driven) * revision directives (actionable bullets) * recommended status transition (`REVIEW_READY` or `REVISION_NEEDED`) --- ## 7) Cadence Enforcement Cadence rules come from the template and influence both PLAN and REVIEW: * PLAN may select parts with missing required beats (per-part cadence) * REVIEW may fail a part if required beats are not reflected in prose (when configured) Template cadence: **[Schema Templates](Schema-Templates.md)** --- ## 8) Implementation Notes (Recommended) * Build the hydration payload as JSON first (for testing/logging). * Render to text prompt deterministically from the payload. * Log the hydrated payload with redactions (keys, tokens). * Token-limit each section to prevent prompt overflow. --- ## 9) Related Pages * **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** * **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** * **[Schema Templates](Schema-Templates.md)** * **[Schema Outline](Schema-Outline.md)** * **[Central Matrix](Central-Matrix-Runtime-State.md)** * **[RAG Memory System](RAG-Memory-System.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Runtime/Provider-Adapter-Grok.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 69a80a2d4c5e829695fd1adb8720b670a21a062f4dd9c2ac800f357595753b84 CONTENT_BYTES: 4990 ================================================================================================ # Provider Adapter Grok > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** SwarmCraft is powered by **Grok** through a dedicated **provider adapter** layer. Goal: - keep the engine **provider-agnostic** - centralize API config, retries, and error handling - normalize responses into a stable internal interface for personas and tools This page documents the expected behavior of the Grok adapter, without tying the rest of the codebase to Grok-specific response shapes. --- ## 1) Responsibilities of the Provider Adapter The Grok adapter MUST: 1. Build requests from SwarmCraft’s internal prompt format. 2. Send requests to Grok with correct auth + model settings. 3. Normalize responses into: - `text` output - optional structured tool calls - token usage and latency metrics (if provided) 4. Apply robust retry/backoff rules. 5. Emit consistent errors for the orchestrator to handle deterministically. The adapter SHOULD: - support multiple Grok models/profiles - support streaming responses (optional) - redact secrets in logs --- ## 2) Internal Provider Interface (Recommended) SwarmCraft should call providers through a stable interface like: ```python class LLMProvider: def generate(self, messages, tools=None, tool_choice=None, **opts) -> ProviderResult: ... ```` Where `ProviderResult` is normalized: ```json { "text": "string", "tool_calls": [ { "name": "write_file", "arguments": { "path": "...", "content": "..." } } ], "usage": { "input_tokens": 0, "output_tokens": 0, "total_tokens": 0 }, "meta": { "model": "grok-...", "latency_ms": 0 } } ``` This allows the orchestrator to remain unchanged if you later add other providers. --- ## 3) Configuration (Recommended) ### 3.1 Environment variables Recommended keys (names may vary by implementation): * `GROK_API_KEY` * `GROK_MODEL` (default model id) * `GROK_BASE_URL` (optional, if not default) ### 3.2 Project-level overrides Optional per-project settings file, e.g.: * `projects//data/settings.json` Recommended fields: ```json { "llm": { "provider": "grok", "model": "grok-...", "temperature": 0.7, "max_tokens": 2000 } } ``` --- ## 4) Tool Calling and Safety SwarmCraft personas must not write files directly. They request tool calls. The Grok adapter MUST support: * passing tool schemas (function definitions) * receiving tool calls (structured) * returning them to the tool executor layer Tool execution remains in SwarmCraft (not in Grok): * the engine validates and runs tools * tool results can be appended to the conversation as tool messages (implementation detail) This preserves deterministic safety rules: * path sandboxing * atomic writes * audit logs --- ## 5) Retries and Error Handling (Recommended) ### 5.1 Retry classes Adapter SHOULD retry on: * transient network failures * 5xx server errors * timeouts Adapter SHOULD NOT retry blindly on: * auth failures (401/403) * invalid request payload (4xx) * tool schema mismatch errors (fix required) ### 5.2 Backoff Use exponential backoff with jitter. ### 5.3 Deterministic surfacing Adapter errors MUST be normalized into stable error codes so the orchestrator can: * mark task as failed * re-plan * pause if needed Example normalized error: ```json { "error": { "code": "PROVIDER_TIMEOUT", "message": "Request timed out after 60s", "retryable": true } } ``` --- ## 6) Token and Cost Tracking (Optional) If Grok provides usage metadata, the adapter SHOULD emit it in `ProviderResult.usage`. If usage is not provided, SwarmCraft MAY estimate tokens separately, but should mark them as estimates. Token tracking integrates with dashboard/cost panels: * **[Dashboard TUI Reference](Dashboard-TUI-Reference.md)** --- ## 7) How Grok Fits the Deterministic Pipeline The provider is invoked only during **EXECUTE** (and optional planning calls if you LLM-assist planning). The pipeline remains: * SCAN: no provider calls required * PLAN: deterministic selection (optionally assisted) * EXECUTE: provider call(s) for one Part, one action Pipeline: **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** --- ## 8) Related Pages * **[Architecture Overview](Architecture-Overview.md)** * **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** * **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** * **[Dashboard TUI Reference](Dashboard-TUI-Reference.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Runtime/RAG-Memory-System.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 089449b944e026aca24a02f49546f533bb91b0feb220eb33f3777f85854e9288 CONTENT_BYTES: 5359 ================================================================================================ # RAG Memory System > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** SwarmCraft uses **Retrieval Augmented Generation (RAG)** as an explicit long-term memory layer to maintain continuity across large stories. RAG is not the Story Bible (intent). RAG is not the Matrix (runtime state). RAG is **evidence**: previously written text and relevant notes that can be retrieved and injected into the current Part’s prompt. --- ## 1) Why RAG Exists LLMs have limited context windows. Without memory, long projects drift: - character traits change - facts get contradicted - timeline breaks - names/places mutate RAG solves this by: - indexing written prose and notes as searchable chunks - retrieving only the top relevant snippets for the active Part - injecting them as bounded “evidence” during drafting and review --- ## 2) What RAG Stores Recommended indexed sources: - Part manuscripts (`data/manuscripts/*.md`) - Editor notes (optional) - stable reference notes (optional, if you want them searchable) RAG SHOULD store per-chunk metadata: - `project_id` - `part_id` (if applicable) - `chapter_id` (if applicable) - `source_path` - `timestamp` - optional tags (character names, location IDs) RAG MUST NOT be treated as canonical intent. If RAG conflicts with Story Bible, Story Bible wins. See: **[Story Bible](Story-Bible-Creative-Intent.md)** --- ## 3) Storage Location (Per Project) Recommended location: - `projects//data/memory_db/` This ensures multi-project isolation and avoids cross-story contamination. See: **[Multi-Project Management](Multi-Project-Management.md)** --- ## 4) Ingestion (Write Path) Ingestion typically occurs during **SCAN**. Flow: 1. Scanner detects changed manuscript files. 2. File is chunked into semantic segments (paragraphs or sections). 3. Each chunk is embedded (vectorized). 4. Vectors + metadata are stored in the project’s vector database. Deterministic pipeline: **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** ### 4.1 Chunking recommendations - chunk by paragraph boundaries when possible - target 150–500 tokens per chunk (implementation-dependent) - include stable headers in metadata rather than duplicating them in every chunk ### 4.2 Deduplication recommendations - hash chunk text + source to avoid re-inserting identical chunks - update metadata timestamps on re-ingest --- ## 5) Retrieval (Read Path) Retrieval occurs during **prompt hydration** for a Part. Flow: 1. Orchestrator builds a query set from: - the Part contract fields (goal/obstacle/turn/outcome) - high-signal beats (Plot/Conflict) - explicit continuity questions (if present) 2. Vector search returns top-k relevant chunks. 3. Orchestrator formats them as “evidence” and injects them into the prompt. Prompt hydration: **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** ### 5.1 Bounded retrieval (required) To prevent prompt bloat: - `top_k` MUST be bounded (e.g., 5–10) - total evidence tokens MUST be bounded - prefer fewer, higher-confidence chunks over many weak chunks ### 5.2 Evidence formatting (recommended) Format each retrieved chunk with: - source + part ID - a short excerpt - optional “why retrieved” hint Example: ```text [RAG] Source: P014.md (CH05 / P014) - "Mara always keeps her left hand gloved..." ```` --- ## 6) RAG in Drafting vs Reviewing ### 6.1 Narrator (Draft/Revise) Use RAG to: * preserve continuity facts * recall prior scene outcomes * maintain consistent voice and details ### 6.2 Editor (Review) Use RAG to: * verify consistency (“does this contradict earlier text?”) * confirm details (names, timeline, injuries, locations) Editor should treat RAG as evidence, not instructions. --- ## 7) Interfaces and Tools (Recommended) Expose RAG through a small tool surface, e.g.: * `memory.query(text, top_k=...)` * optional: `memory.query_filters(part_id=..., chapter_id=...)` Recommended role rules: * Narrator can request retrieval through orchestrator hydration, but does not directly call DB. * Editor may call a controlled `check_memory` tool for spot checks. --- ## 8) Failure Modes and Guards * **Hallucinated “memories”**: mitigate by only injecting retrieved text excerpts. * **Cross-project bleed**: mitigate with per-project DB path + required `project_id` filter. * **Contradicting intent**: Story Bible overrides RAG; Editor should flag conflicts. * **Prompt overflow**: enforce strict token budgets for evidence. --- ## 9) Related Pages * **[Architecture Overview](Architecture-Overview.md)** * **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** * **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** * **[Story Bible](Story-Bible-Creative-Intent.md)** * **[Central Matrix](Central-Matrix-Runtime-State.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Scaffold/Outline-Grid-CSV-Round-Trip.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 6dc939326c179b3337e332f0ab949fc310fddedad4a467b3fe75e75c15494283 CONTENT_BYTES: 5638 ================================================================================================ # Outline Grid CSV Round-Trip > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** SwarmCraft supports a **human-friendly grid editor** for the outline and a **CSV round-trip** workflow. Goal: - Humans can edit the scaffold like a spreadsheet. - The system can import/export without losing structure. - Stable Part IDs preserve meaning across edits. This page specifies how `outline.json` maps to a grid and how CSV import/export should behave. --- ## 1) Grid Model ### 1.1 What the grid shows - **Columns**: Parts (ordered by chapter then part order) - **Rows**: Threads (from the active template) - **Cells**: A thread beat for that Part Source of truth: - Threads come from `templates/.json` See: **[Schema Templates](Schema-Templates.md)** - Beats come from `outline.json` See: **[Schema Outline](Schema-Outline.md)** ### 1.2 What is NOT in the grid (by default) - Part contract fields (goal/obstacle/turn/outcome) These may be shown in a separate panel, side sheet, or a second table export format. - Manuscripts (prose) are not in the outline grid. --- ## 2) Canonical Mapping: Outline → Grid Given: - `threads = template.threads[]` - ordered parts = `for each chapter in chapters[]: chapter.part_ids[]` Cell mapping: ``` cell(thread, part_id) = outline.parts[part_id].beats[thread] (string or empty) ```` If the key is missing, treat it as empty when projecting: - missing beat keys MUST NOT break UI or export - export should emit an empty string for missing cells --- ## 3) CSV Export Format (Beats Grid) ### 3.1 Shape - First column: thread name - Remaining columns: `Part 1`, `Part 2`, … in display order - Optional second header row: stable `part_id` values (recommended) The beats-only CSV is a projection of the grid (threads × parts). ### 3.2 Recommended headers (two-row header) Row 1 (human labels): - column 1: empty or `Thread` - columns 2..N: `Part 1`, `Part 2`, … (or chapter-aware labels) Row 2 (machine IDs): - column 1: `part_id` - columns 2..N: `P001`, `P002`, … This allows the CSV to remain stable even if “Part 3” is moved into a different chapter. ### 3.3 Example ```csv ,Part 1,Part 2,Part 3 part_id,P001,P002,P003 Plot,"The World in Turmoil...","The Revelation...","A Seed of Hope..." Character Development,"King Klown feels helpless...","Insight sparks vision...","Cautious optimism..." Conflict,"Global crisis escalates...","Self-doubt...","Opposition begins..." ```` --- ## 4) CSV Import Rules (Beats Grid) ### 4.1 Primary key: part_id row Import SHOULD use the `part_id` row as the canonical mapping. * If present, `part_id` row MUST be used. * If absent, importer MAY fall back to positional mapping (less safe). ### 4.2 Thread name matching Rows are matched by thread name (first column). * Exact match is recommended. * Whitespace trimming is recommended. * Unknown thread names: * either reject with validation error, or * store in `outline.parts[*].beats` only if the system supports custom threads (not recommended by default) ### 4.3 Lock compliance (required) Importer MUST respect outline locks: * If `outline.parts[part_id].locks.beats == true`, that part’s beats MUST NOT be modified by CSV import. Recommended behavior: * import produces a report: * updated cells count * skipped due to locks * unknown threads * unknown part_ids --- ## 5) Handling Template Changes (Thread Set Changes) If the user changes template (or template version): * The grid row set changes (threads list changes) * The system SHOULD provide a migration layer: * missing threads: create empty beats * removed threads: preserve in outline as “orphaned” beats only if explicitly enabled, otherwise drop with confirmation Recommended: do not silently delete beats. --- ## 6) Parts/Chapter Changes (Column Reflow) If the user changes `parts_per_chapter`: * Part IDs must remain stable. * The UI may re-group columns under different chapters. * CSV export order may change, but the `part_id` row remains stable. Rule: * do not rename existing part IDs when reflowing chapters * generate new part IDs only when new parts are created --- ## 7) Optional: Contract CSV Export Beats CSV is intentionally simple. If you want contract editing in CSV, use a second file: `outline_contract.csv` (recommended) Shape: ```csv part_id,chapter_id,title,goal,obstacle,turn,outcome P001,CH01,Part 1,"...","...","...","..." ``` Contract import MUST respect `locks.contract`. --- ## 8) Relationship to Writing and Orchestration The grid is a scaffold. The engine uses it slice-by-slice: * during PLAN to detect missing beats (cadence) * during EXECUTE to inject only the active Part slice * during REVIEW to validate manuscript coverage of beats + contract See: * **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** * **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** --- ## 9) Related Pages * **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** * **[Schema Templates](Schema-Templates.md)** * **[Schema Outline](Schema-Outline.md)** * **[Central Matrix](Central-Matrix-Runtime-State.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Scaffold/Schema-Outline.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 971e11e6c0efee74945a9947565c5ebe652e2902e0d72df59d3e13b18b5d3bbf CONTENT_BYTES: 6319 ================================================================================================ # Schema Outline > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** `outline.json` is the canonical **story plan** for a project. It defines: - chapter ordering - chapter → parts mapping - per-part thread beats (grid cells) - per-part contract (goal / obstacle / turn / outcome) - locks to protect manual edits File location: - `data/story_bible/outline.json` Story scaffold overview: **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** --- ## 1) Design Goals The outline MUST support: - user-chosen parts/chapter (within template bounds) - stable part IDs (critical for tracking and CSV round-trip) - different template thread sets - per-part beat editing in a grid UI - per-part contract strictness for slice-by-slice drafting - lock scopes (beats / contract / manuscript) The outline SHOULD: - be readable to humans - be resilient to partial data (empty beats allowed) - be forward-compatible (versioned) --- ## 2) Minimal Outline Schema (Recommended) ```json { "version": 1, "template_id": "novel.default", "settings": { "parts_per_chapter": 3 }, "chapters": [ { "chapter_id": "CH01", "title": "The World in Turmoil", "summary": "Global crisis exposes systemic failure.", "part_ids": ["P001", "P002", "P003"] } ], "parts": { "P001": { "chapter_id": "CH01", "title": "Part 1", "order_index": 1, "contract": { "goal": "Show the world failing in a concrete, personal way.", "obstacle": "Institutions deny and deflect responsibility.", "turn": "A specific event forces the truth into the open.", "outcome": "King Klown realizes the crisis is structural, not isolated." }, "beats": { "Plot": "The World in Turmoil: global crisis exposes systemic failure.", "Character Development": "King Klown feels helpless and isolated.", "Conflict": "External disaster + internal doubt collide.", "Themes": "Collapse and urgent need for change.", "World-Building": "Introduce fractured institutions and scarcity.", "Emotion": "Despair and urgency.", "Symbolism and Imagery": "Fractured world as collective neglect.", "Structure": "Open with stakes and central conflict.", "Relationships": "King Klown is disconnected from others." }, "locks": { "beats": false, "contract": false, "manuscript": false } } } } ```` Notes: * `chapters[]` defines the ordered reading structure. * `parts{}` is the canonical per-part content. * `beats` keys should match template threads. --- ## 3) Field Semantics ### 3.1 `version` (required) Schema version for migration and validation. ### 3.2 `template_id` (required) Must match an existing template file in: * `templates/.json` Template schema: **[Schema Templates](Schema-Templates.md)** ### 3.3 `settings.parts_per_chapter` (recommended) User override of parts/chapter within template bounds. If omitted, the engine may use the template default. ### 3.4 `chapters[]` (required) Ordered list of chapters. Each chapter SHOULD contain: * `chapter_id` (stable ID) * `title` * optional `summary` * `part_ids` ordered list (critical) ### 3.5 `parts{}` (required) Map of Part IDs to Part objects. Each Part MUST contain: * `chapter_id` (must match one chapter) * `order_index` (global or chapter-local; implementation choice) * `beats` object * `contract` object (recommended) * `locks` object (recommended) --- ## 4) Part Contract (Strict Slice Anchor) The **contract** is the minimum “what must happen” spec for a Part. Recommended fields: * `goal` * `obstacle` * `turn` * `outcome` The orchestrator uses the contract to: * hydrate slice prompts * give the Editor a rubric for validation Related: * **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** --- ## 5) Beat Keys and Template Compatibility Beat keys MUST align with the active template’s threads. Validation SHOULD ensure: * every `beats` key exists in `template.threads` * missing keys are treated as empty when projecting to grid/CSV * extra keys are flagged (or preserved if you support custom threads) --- ## 6) Locks (Manual Edit Protection) Locks prevent automation from overwriting human edits. Recommended lock scopes: * `beats`: prevents automated changes to beats * `contract`: prevents automated changes to contract * `manuscript`: prevents automated changes to prose file Planner rule: * PLAN MUST NOT select a part for an action that violates locks. Matrix mapping: * locked parts should appear as `LOCKED` (or `locked=true`) in Matrix. Matrix: **[Central Matrix](Central-Matrix-Runtime-State.md)** --- ## 7) ID Stability Rules (Critical) * `chapter_id` and `part_id` MUST be stable once created. * Grid and CSV round-trip depend on stable `part_id`. * Changing parts/chapter SHOULD preserve existing part IDs where possible. * New splits SHOULD create new part IDs instead of renaming existing parts. --- ## 8) Relationship to Grid and CSV The outline is projected into a grid for human editing: * rows = template threads * columns = parts (ordered by chapters / part_ids) * cells = outline.parts[part_id].beats[thread_name] Round-trip rules: * CSV export is a projection of `beats` * CSV import updates `beats` while respecting locks See: **[Outline Grid CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** --- ## 9) Relationship to Manuscripts and Matrix * Outline defines intent (beats + contract). * Manuscripts contain prose generated for each Part. * Matrix tracks runtime status and file metrics. See: * **[Story Bible](Story-Bible-Creative-Intent.md)** * **[Central Matrix](Central-Matrix-Runtime-State.md)** * **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Scaffold/Schema-Templates.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 43d5ff589ca5a86f250a377fe2d7a16b63ccd3bb67ab8be923171120d69b00f2 CONTENT_BYTES: 4945 ================================================================================================ # Schema Templates > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** Templates define the **shape and pacing rules** of the Story Scaffold. A template file lives at: - `data/story_bible/templates/.json` It defines: - thread set (grid rows) - cadence rules (what must be filled, how often) - default parts/chapter + allowed bounds - optional style/genre constraints used in prompt hydration Story scaffold overview: **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** --- ## 1) Design Goals Templates MUST support: - multiple genres / formats (children book, novel, screenplay, etc.) - user-chosen parts/chapter within allowed bounds - different thread sets per template - enforceable cadence (required beats per part or per chapter) - stable projection into a grid and CSV Templates SHOULD: - remain small and readable for humans - avoid storing story-specific content (that belongs in `outline.json`) --- ## 2) Minimal Template Schema (Recommended) ```json { "template_id": "novel.default", "name": "Novel (Default)", "version": 1, "threads": [ "Plot", "Character Development", "Conflict", "Themes", "World-Building", "Emotion", "Symbolism and Imagery", "Structure", "Relationships" ], "parts_per_chapter": { "default": 3, "min": 1, "max": 6 }, "cadence": { "per_part_required_threads": ["Plot", "Conflict"], "per_chapter_required_threads": ["Character Development", "Themes"], "soft_threads": ["Symbolism and Imagery", "World-Building"], "min_non_empty_cells_per_part": 3 }, "prompting": { "target_reading_level": "adult", "tone": ["clear", "cinematic"], "pov": "third_limited", "tense": "past", "hard_constraints_refs": [ "constraints/hard_rules.md", "constraints/style_guide.md" ] } } ```` Notes: * `threads` defines the grid rows. * `parts_per_chapter` defines defaults and bounds; users can override within bounds. * `cadence` defines what the planner/editor should enforce. * `prompting` provides reusable style constraints (optional). --- ## 3) Field Semantics ### 3.1 `template_id` (required) Stable identifier used by the project config and Story Bible. ### 3.2 `threads` (required) Ordered list of thread names. * Order is the default order in the grid UI. * Thread names must match outline beat keys (see Schema Outline). ### 3.3 `parts_per_chapter` (required) Defines allowed splitting: * `default`: recommended parts/chapter for this format * `min`, `max`: permitted bounds for user override ### 3.4 `cadence` (recommended) Cadence is enforcement guidance for PLAN/REVIEW. Recommended keys: * `per_part_required_threads`: must be non-empty in every part (unless explicitly waived) * `per_chapter_required_threads`: must appear at least once per chapter (rollup check) * `soft_threads`: encouraged but optional * `min_non_empty_cells_per_part`: guard against under-specified parts Cadence is a rule set for scaffold completeness; it does not guarantee prose quality. ### 3.5 `prompting` (optional) Reusable prompt constraints and references: * reading level / audience * tone and voice * POV and tense * references into Story Bible Markdown files If present, prompt hydration can include these in every Part slice. --- ## 4) Template Variants (Examples) ### 4.1 `children.picturebook.json` Typical guidance: * fewer threads * `parts_per_chapter.default = 1` * tighter cadence (Plot + Emotion required every part) ### 4.2 `novel.default.json` Typical guidance: * broader thread set * `default = 3` parts/chapter * encourages symbolism/worldbuilding but doesn’t require every part ### 4.3 `screenplay.default.json` Typical guidance: * threads oriented around beats, scene function, visuals * strict structure cadence (inciting incident, midpoint, etc.) via outline contract usage --- ## 5) Validation Rules (Recommended) A validator SHOULD enforce: * `threads` is non-empty and has unique strings * `parts_per_chapter.min <= default <= max` * cadence thread names must exist in `threads` * version is present and numeric --- ## 6) Relationship to Outline and Grid * Template defines the *thread rows* and pacing rules. * Outline defines the *per-part cell content*. Related: * **[Schema Outline](Schema-Outline.md)** * **[Outline Grid CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** * **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** ================================================================================================ FILE: Rejean-en/SwarmCraft/Scaffold/Story-Bible-Creative-Intent.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 05a2f2ff026092bb177b6c23fa40366ca858b228235f28e9f7802ccd22f47924 CONTENT_BYTES: 3112 ================================================================================================ # Story Bible (Creative Intent) > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** The **Story Bible** is SwarmCraft’s home for **creative intent**: the canonical narrative plan, constraints, and reference material that guide drafting and revision. It is designed to be: - **explicit** (no hidden “chat history” requirements) - **versionable** (text/JSON files under source control) - **sliceable** (only the relevant subset is injected into prompts) - **human-editable** (writers can edit directly or through UI) The Story Bible is distinct from: - **Matrix** (runtime progress state): **[Central Matrix](Central-Matrix-Runtime-State.md)** - **RAG memory** (retrieved continuity evidence): **[RAG Memory System](RAG-Memory-System.md)** --- ## 1) Location and Project Isolation **Recommended per-project location:** - `projects//data/story_bible/` Single-project setups MAY use: - `data/story_bible/` The Story Bible is project-scoped. Each project has its own Bible and must not share it implicitly. See: **[Multi-Project Management](Multi-Project-Management.md)** --- ## 2) What Lives in the Story Bible SwarmCraft treats the Story Bible as the canonical source for: ### 2.1 Canonical references - Characters (bios, arcs, secrets, voice constraints) - Locations (maps, rules, sensory signatures) - Lore (history, factions, magic/tech rules) - Style rules (tone, POV, reading level, taboo list) - Constraints (hard rules the Editor enforces) These may be stored in Markdown or JSON, depending on preference and tooling. ### 2.2 The Story Scaffold (New) The scaffold is part of the Story Bible because it is **creative intent**, not runtime state: - **Templates:** `templates/.json` Defines threads (Plot, Character Development, etc.), cadence expectations, and default parts/chapter. - **Outline:** `outline.json` Defines chapters → parts mapping, per-part thread beats, and per-part “contract”. Scaffold entry point: - **[Story Scaffold](Story-Scaffold-Templates-Outline-Parts.md)** --- ## 3) Recommended Folder Layout Example: ```text projects//data/story_bible/ ├── README.md ├── outline.json ├── templates/ │ ├── children.picturebook.json │ ├── novel.default.json │ └── screenplay.default.json ├── characters/ │ ├── king_klown.md │ └── ... ├── locations/ │ ├── cosmic_council_hall.md │ └── ... ├── lore/ │ ├── world_rules.md │ └── ... ├── constraints/ │ ├── hard_rules.md │ └── style_guide.md └── glossaries/ └── terms.md ================================================================================================ FILE: Rejean-en/SwarmCraft/Scaffold/Story-Scaffold-Templates-Outline-Parts.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 9527f0dae0ce34aec90928128873fdd914144cbee8b6a89b04c8e58b856388cb CONTENT_BYTES: 5028 ================================================================================================ # Story Scaffold (Templates-Outline-Parts) > **Architectural Lineage (Credits):** > SwarmCraft is an **architectural fork and deep rewrite** of the multi-agent swarm engine created by **[Mojomast](https://github.com/mojomast)** in **[mojomast/swarmussy](https://github.com/mojomast/swarmussy)**. > SwarmCraft’s deterministic “Architect-style” layering is also **derived from the meta-structure of Abstract Wiki Architect (AWA)**. > Full details: **[Credits & Lineage](Credits-And-Lineage.md)** ## **POWERED BY GROK** The **Story Scaffold** is SwarmCraft’s structured planning layer used to generate and maintain narrative coherence. It is designed as a **human-editable grid** and a **machine-usable schema**. It combines: - **Templates**: what threads exist and how they should be paced - **Outline**: chapters → parts mapping + per-part beats + part contracts - **Parts**: the atomic unit the engine drafts/revises The Scaffold lives inside the Story Bible: - `data/story_bible/templates/.json` - `data/story_bible/outline.json` See: **[Story Bible](Story-Bible-Creative-Intent.md)** --- ## 1) Why Parts Exist SwarmCraft drafts and revises **one Part at a time**. A Part is the atomic unit because it enables: - stable, small prompt slices - targeted regeneration (one slice) - better continuity control - precise status tracking in Matrix Chapters are **rollups** over Parts. Related: - **[Central Matrix](Central-Matrix-Runtime-State.md)** - **[Deterministic Pipeline](Deterministic-Pipeline-Scan-Plan-Execute.md)** --- ## 2) Threads (Narrative Lanes) A template defines the thread set used to structure the story, e.g.: - Plot - Character Development - Philosophy - Conflict - Themes - World-Building - Emotion - Symbolism and Imagery - Structure - Relationships Threads are not the final prose. They are **scaffolding lanes** the engine uses to plan and draft. --- ## 3) Templates: Thread Set + Cadence + Default Parts/Chapter A **template** defines: - the thread list (rows in the grid) - cadence rules (which threads are required per part/chapter, and at what frequency) - default and allowed ranges for parts/chapter - optional genre voice constraints Schema: **[Schema Templates](Schema-Templates.md)** --- ## 4) Outline: Chapters → Parts + Per-Part Beats + Part Contract The **outline** is the canonical story plan for a project. It defines: - chapters and their ordered parts - for each part: - beats per thread (grid cells) - a “part contract” (goal / obstacle / turn / outcome) - optional locks (protect manual edits) Schema: **[Schema Outline](Schema-Outline.md)** --- ## 5) Grid View (Human Editing) The UI projects the outline into a grid: - Columns = Parts (`P001`, `P002`, …) - Rows = Threads (Plot, Character Dev, etc.) - Cells = the beat for that thread in that part This is designed to be: - quick to scan - easy to edit manually - compatible with CSV round-trip when needed Round-trip spec: **[Outline Grid CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** --- ## 6) How the Scaffold Drives Writing During execution, SwarmCraft hydrates prompts with **only the active Part slice**: - that Part’s thread beats - that Part’s contract - minimal continuity (previous part outcome, relevant character/lore snippets) - style constraints This prevents the system from “re-summarizing the whole story” every time. Details: **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** --- ## 7) Parts/Chapter: User-Configurable Splitting Templates provide defaults, but the user can override: - **Children / picture book:** typically `1 part = 1 chapter` - **Novel:** often `3 parts/chapter` (default example) - **Complex long-form:** up to `6 parts/chapter` where needed Important constraint: - parts must have stable IDs; changing parts/chapter should preserve existing part IDs wherever possible, or explicitly create new parts with new IDs. --- ## 8) Orchestration Expectations (Recommended) The engine SHOULD: - treat empty cells as “no beat required” unless cadence says otherwise - enforce cadence at plan-time (PLAN chooses what needs filling) - use Editor to verify manuscript covers the contract + beats - lock parts once stable to avoid regressions --- ## 9) How This Relates to Matrix - **Outline** is creative intent. - **Matrix** is runtime progress. Matrix stores: - status per Part (EMPTY/DRAFTING/REVIEW_READY/REVISION_NEEDED/LOCKED) - manuscript paths and metrics - active_task target Matrix page: **[Central Matrix](Central-Matrix-Runtime-State.md)** --- ## 10) Related Pages - **[Story Bible](Story-Bible-Creative-Intent.md)** - **[Schema Templates](Schema-Templates.md)** - **[Schema Outline](Schema-Outline.md)** - **[Outline Grid CSV Round-Trip](Outline-Grid-CSV-Round-Trip.md)** - **[Orchestration Slice-by-Slice Prompt Hydration](Orchestration-Slice-By-Slice-Prompt-Hydration.md)** - **[Central Matrix](Central-Matrix-Runtime-State.md)** ================================================================================================ FILE: Rejean-en/Tools/index.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 1a86a3fb2f810d39d45ad079d0e76b65da89fc9e96a2922c57d46cf3291a54c5 CONTENT_BYTES: 3920 ================================================================================================ ## AI-Assisted Development Workflow Toolkit **Component:** Project Analysis, Code Extraction, and LLM Integration **Role:** Automates the creation of highly precise, context-rich prompts for Large Language Models (LLMs) and manages the subsequent code re-integration. --- ## 1. Overview and Methodology This toolkit is a specialized workflow designed to create a tight feedback loop between a code repository and an external AI service (like ChatGPT) for systematic code analysis and modification. It orchestrates several Python scripts and configuration data to achieve granular control over which parts of the codebase are analyzed and updated. ### Core Workflow Principle (Scan $\rightarrow$ Prompt $\rightarrow$ Insert) 1. **Scanning:** Systematically discovers all relevant files in a project directory. 2. **Prompt Generation:** Extracts and concatenates specific, isolated **code blocks** (rather than entire files) to create a highly focused prompt for the LLM. 3. **Re-Integration:** Applies the LLM's output directly back into the repository with high precision using line-aware insertion scripts. --- ## 2. Core Utility Scripts This group of Python scripts performs the essential tasks of path discovery, data extraction, and content modification. | File Name | Function | Details | | :--- | :--- | :--- | | **`scanAppProjectForPaths.py`** | **Path Discovery** | Scans the project using `os.walk` to identify all relevant file paths, generating the initial dataset used by the system. | | **`smart_dump.py`** | **Content Extraction** | Iterates over files defined in the configuration and concatenates their content, often with specific delimiters and headers, for easy input into the LLM. | | **`concatFilesAndSubs.py`** | **Block Substitution** | Combines file contents and performs necessary text substitutions or block replacements based on defined configuration lists. | | **`pythonInsert.py`** | **Precise Code Insertion** | Reads content (typically LLM output) and injects it at a precisely defined line or block marker within target Python files. | | **`openInNotepad.py`** | **Inspection Utility** | A simple utility to quickly open files identified by the workflow in a local text editor (e.g., Notepad) for inspection. | --- ## 3. Data Configuration and Mapping The system's intelligence relies heavily on the structured data provided in these files (exports from `path_blocks_combinedv2.xlsx`), which serve as the configuration layer. | File Name | Role in Workflow | Key Data Defined | | :--- | :--- | :--- | | **`path_blocks_combinedv2.xlsx - Paths.csv`** | **File Index** | The master list of all source files to be considered for analysis. | | **`path_blocks_combinedv2.xlsx - Blocks.csv`** | **Code Isolation** | Defines specific, granular code segments or "blocks" within the files, allowing the prompt to be highly focused (e.g., only a single function definition). | | **`path_blocks_combinedv2.xlsx - Concat_Fetch.csv`** | **Prompt Blueprint** | Specifies the exact sequence of files and blocks that `smart_dump.py` must combine to construct the prompt sent *to* the LLM. | | **`path_blocks_combinedv2.xlsx - Concat_Give.csv`** | **Injection Blueprint** | Specifies the target paths and block markers where the modified code or LLM output must be inserted *into* the repository. | --- ## 4. Automation and Maintenance The workflow is managed by local scripts that handle version control and execution. * **`GitSink.bat`:** A Windows Batch script used to automate common tasks such as triggering the Python scripts in sequence, handling file synchronization, and managing Git operations (e.g., commit/push). This script defines the robust, automated loop for the AI-assisted process. --- ## Installation and Usage *(Instructions for setting up the Python environment, dependencies, and initial execution would go here, sourced from the local `README.md`.)*