GM-RKB - Recent changes [en]

Association Rule

Gmelli-bot-202505 — Wed, 22 Jul 2026 05:39:13 GMT

Enhance Association Rule: rubric 4 -> 8 (PR-002 Silver target). Authorized PR-003.

← Older revision		Revision as of 05:39, 22 July 2026
Line 1:		Line 1:
	An [[Association Rule]] is a [[rule]] that ~~associates~~ two or more [[itemset pattern]]s.		An [[Association Rule]] is a [[data mining rule]] that expresses a co-occurrence relationship between two or more [[itemset pattern]]s in a [[transaction dataset]].
	* <B>~~Context~~</U>:</B>		* <B>AKA:</B> [[Item Association Rule]], [[Market Basket Rule]].
	** It can be produced by an [[Association Rule Learning Task]].		* <B>Context:</B>
	** …		** It can (typically) be produced by an [[Association Rule Learning Task]].
	* <B>~~Example(s)~~:</B>		** It can (typically) consist of an [[antecedent itemset]] and a [[consequent itemset]] connected by an [[implication operator]].
	** {item contains 'Hotdog'} ⇒ {item contains 'Hotdog Bun'},		** It can (typically) be evaluated by an [[association rule interestingness measure]], such as [[support measure\|support]], [[confidence measure\|confidence]], and [[lift measure\|lift]].
	** …		** It can (often) be derived from a [[frequent itemset pattern]] discovered during a [[frequent pattern mining task]].
	* <B>Counter-~~Example(s)~~:</B>		** It can (often) require a [[minimum support threshold]] and a [[minimum confidence threshold]] for its generation.
	** [[Production Rule]].		** It can (often) support [[market basket analysis task]]s for [[retail transaction dataset]]s.
	* <B>See:</B> [[Frequent Itemset Pattern]]; [[Association]]; [[Apriori Algorithm]]; [[Basket Analysis]]; [[Frequent Itemset]]; [[Frequent Pattern]], [[Lift]], [[Confidence]], [[Support]].		** It can range from being a [[Single-Item Association Rule]] to being a [[Multi-Item Association Rule]], depending on its [[itemset cardinality]].
			** It can range from being a [[Positive Association Rule]] to being a [[Negative Association Rule]], depending on its [[itemset correlation]].
			** It can integrate with a [[recommendation system]] for [[cross-selling task]]s.
			** It can inform a [[decision support system]] for [[business intelligence task]]s.
			** ...
			* <B>Examples:</B>
			** [[Retail Association Rule]]s, such as:
			*** {item contains 'Hotdog'} ⇒ {item contains 'Hotdog Bun'}, for [[cross-selling task]]s.
			*** {item contains 'Diaper'} ⇒ {item contains 'Beer'}, for [[shopping pattern analysis task]]s.
			** [[Web Usage Association Rule]]s, such as:
			*** {visited page A} ⇒ {visited page B}, for [[clickstream analysis task]]s.
			** [[Bioinformatics Association Rule]]s, such as:
			*** {gene G1 expressed} ⇒ {gene G2 expressed}, for [[gene expression analysis task]]s.
			** ...
			* <B>Counter-Examples:</B>
			** [[Production Rule]], which encodes an [[expert-defined condition-action mapping]] rather than a [[data-derived co-occurrence]].
			** [[Classification Rule]], which predicts a [[class label]] rather than an [[itemset co-occurrence]].
			** [[Sequential Pattern]], which captures a [[temporal ordering]] rather than an [[unordered co-occurrence]].
			* <B>See:</B> [[Frequent Itemset Pattern]], [[Association]], [[Apriori Algorithm]], [[Basket Analysis]], [[Frequent Itemset]], [[Frequent Pattern]], [[Lift]], [[Confidence]], [[Support]].

	~~----~~
	----		----

Fleet (AGET)

Gmelli-bot-202505 — Sun, 19 Jul 2026 20:32:50 GMT

Enhance: deepen Context (frequency-graduated + range statements), decompose concept graph (43->106 links), add examples/counter-examples, house-style section labels + References. Rubric 8/18 -> 15/18 (PR-002 Silver target). Authorized PR-003.

← Older revision		Revision as of 20:32, 19 July 2026
(One intermediate revision by the same user not shown)
Line 1:		Line 1:
	A [[Fleet (AGET)]] is a [[~~multi-agent coordination unit~~]] in the [[AGET Framework]] ~~consisting of~~ multiple [[AGET ~~Framework\|~~AGET]] ~~agents (typically~~ [[~~Worker~~ AGET]]~~s plus a~~ [[~~Supervisor~~ AGET]]~~) operating under shared~~ [[governance]] ~~policy with~~ [[~~cross~~-~~fleet coordination~~]] ~~capability.~~		A '''Fleet (AGET)''' is an [[Agent Fleet]] instantiated under the [[AGET Framework]] that coordinates multiple [[AGET Agent]]s under a shared [[Governance Policy]] with [[Cross-Fleet Coordination]] capability.
	* ~~AKA~~: [[~~AGET fleet~~]], [[~~AGET portfolio~~]], [[~~fleet~~]].		* <B>AKA:</B> [[AGET Fleet]], [[AGET Agent Fleet]], [[AGET Portfolio]], [[Agent Seat Collection]].
	* ~~Context:~~		* <B>Context:</B>
	** It can typically ~~include~~ one [[Supervisor AGET]] ~~plus N~~ [[Worker AGET]]s ~~of varying~~ [[~~domain~~]] ~~specializations~~.		** <B>[[Fleet Input\|input]]:</B> [[AGET Agent Registration]]s, [[Governance Policy\|governance policy]], [[Fleet Configuration]]
	** It can typically share [[~~substrate~~-OK ~~protocol~~]] signals and [[~~evidence chain~~]]s across ~~member agents~~ via [[~~fleet message~~]]s.		** <B>[[Fleet Output\|output]]:</B> [[Fleet Coordination Decision]]s, [[Cross-Seat Evidence Chain]]s, [[Fleet Health Report]]s
	** It can ~~typically operate against shared~~ [[~~substrate~~]] (e.g., a [[~~wiki~~]], [[~~EC2 instance~~]], [[~~knowledge base~~]]).		** <B>[[Fleet Measure\|measure]]:</B> [[Fleet Seat Count]], [[Fleet Governance Conformance]], [[Cross-Seat Drift]]
	** It can ~~typically apply~~ [[~~uniform governance~~]] ~~policy across all member~~ [[~~Worker AGET~~]]s.		** ...
	** It can ~~support~~ [[~~cross~~-~~fleet sequencing~~]] ~~via~~ [[~~R-row binding~~]]s and [[~~joint maintenance window~~]]s ~~with sibling fleets~~.		** It can (typically) contain one [[Supervisor AGET]] and multiple [[Worker AGET]]s, each holding a distinct [[Agent Domain Scope]].
	* ~~Examples~~:		** It can (typically) enforce a [[Uniform Governance Policy]] across member seats, covering [[Session Protocol]]s, [[Skill Naming Convention]]s, and [[Evolution Document]] practice.
	** ~~The~~ [[GM-RKB ~~fleet~~]] ~~consisting~~ of [[private-RKB-CONTENT_ENHANCER-aget\|content enhancement ~~AGET~~]], [[private-it-~~consultant~~-aget\|~~IT consultant AGET~~]], and [[private-~~supervisor~~-AGET]].		** It can (typically) share a [[Fleet Substrate]], such as a [[Wiki Substrate]], a [[Compute Substrate]], or a [[Knowledge Base Substrate]].
	* Counter-~~Examples~~:		** It can (typically) propagate [[Framework Version]] upgrades through a [[Fleet Upgrade Lifecycle]], so member seats converge on one [[Framework Release]].
	** ~~A single standalone~~ [[~~Worker AGET~~]], which lacks [[~~fleet (AGET)\|fleet~~]]~~-level coordination~~.		** It can (typically) exchange [[Fleet Message]]s carrying [[Substrate-OK Protocol]] signals and [[Evidence Chain]]s between seats.
	** A [[~~multi~~-~~agent system~~]] ~~without shared~~ [[~~AGET~~ Framework]] [[~~governance~~]], ~~lacking~~ [[~~L-doc~~]] [[~~learning persistence~~]].		** ...
	* See: [[AGET Framework]], [[~~Worker~~ AGET]], [[~~Supervisor~~ AGET]], [[Multi-Agent System]], [[Cross-Fleet Coordination]].		** It can (often) designate [[Stewardship Ownership]] for shared vocabularies, so a [[Framework Vocabulary]] has exactly one [[Steward Seat]].
			** It can (often) coordinate a [[Joint Maintenance Window]] across seats sharing one substrate, sequenced via [[R-Row Binding]]s.
			** It can (often) route work between seats via [[Inter-Agent Communication]], such as an [[Inbox Handoff]] or a [[Steward Advisory]].
			** It can (often) constrain a member seat to [[Read-Only Cross-Seat Access]], so one seat may audit another without write authority.
			** It can (often) accumulate [[Cross-Seat Learning]] as [[Learning Document]]s that outlive any single [[Software Session]].
			** ...
			** It can range from being a [[Personal Agent Fleet]] to being an [[Organizational Agent Fleet]], depending on its [[Fleet Scale]].
			** It can range from being a [[Homogeneous Agent Fleet]] to being a [[Heterogeneous Agent Fleet]], depending on its [[Domain Specialization Spread]].
			** It can range from being a [[Single-Portfolio Fleet]] to being a [[Multi-Portfolio Fleet]], depending on its [[Portfolio Topology]].
			** It can range from being a [[Loosely-Governed Fleet]] to being a [[Strictly-Governed Fleet]], depending on its [[Governance Intensity]].
			** ...
			** It can be distinguished from an [[Ad-Hoc Agent Collection]] by its shared [[Governance Policy]] and [[Fleet Upgrade Lifecycle]].
			** It can suffer [[Canon Version Skew]] when member seats run divergent copies of a [[Canonical Specification]].
			** It can exhibit [[Correlated Seat Error]] when multiple seats reason from one [[Contaminated Source Artifact]], which resembles [[Independent Corroboration]] but is not.
			** It can require a [[Seat Abbreviation Registry]] if [[Skill Namespace]]s are qualified per seat.
			** ...
			* <B>Example(s):</B>
			** the [[GM-RKB Fleet]], composed of [[private-RKB-CONTENT_ENHANCER-aget\|a content-enhancement seat]], [[private-RKB-analytics-aget\|an analytics seat]], and [[private-RKB-infra-aget\|an infrastructure seat]], sharing the [[GM-RKB Wiki]] as substrate.
			** the [[AGET Framework Fleet]], in which a [[Framework Steward Seat]] owns [[Skill Naming Convention]] and [[Framework Vocabulary]] decisions for other seats.
			** a [[Supervised Agent Fleet]] in which a [[Supervisor AGET]] performs [[Fleet Health Check]]s and [[Fleet Version Sweep]]s across member seats.
			** a [[Cross-Portfolio Fleet]] spanning [[Agent Portfolio]]s with differing [[Canonical Path Resolution]] layouts.
			** ...
			* <B>Counter-Example(s):</B>
			** an [[Ad-Hoc Agent Collection]], which lacks shared [[Governance Policy]] and a common [[Fleet Upgrade Lifecycle]].
			** a [[Multi-Agent System]] of independently-owned agents, which coordinates behavior but shares no [[Framework Version]] or [[Learning Document]] practice.
			** a [[Stateless Service Replica Pool]], whose members are interchangeable instances rather than seats with distinct [[Agent Domain Scope]]s.
			** a single standalone [[Worker AGET]], which has no [[Cross-Fleet Coordination]] surface.
			* <B>See:</B> [[Agent Fleet]], [[AGET Framework]], [[Supervisor AGET]], [[Worker AGET]], [[Multi-Agent System]], [[Cross-Fleet Coordination]], [[Governance Policy]], [[Software Session]].
			----
			== References ==

			=== 2026 ===
			* Published from the [https://github.com/aget-framework AGET framework]; machine-readable concept: [https://w3id.org/aget/vocab#Fleet w3id.org/aget/vocab#Fleet]

	[[Category:AI Agent]]		[[Category:AI Agent]]

Protocol

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:42:12 GMT

GPP wave-1: enhance Protocol (cross-link, AGET dual-surface)

← Older revision		Revision as of 07:42, 19 July 2026
Line 27:		Line 27:
	__NOTOC__		__NOTOC__
	[[Category:Concept]]		[[Category:Concept]]
			* [[Initialization Protocol]] — a startup protocol that loads an agent's identity and context before work begins.
			* [[Session Protocol]] — a protocol governing a phase of a [[Software Session]]'s lifecycle.

V-Test

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:41:31 GMT

GPP wave-1: alias redirect to Verification Test

New page

#REDIRECT [[Verification Test]]

Wake-Up Protocol

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:40:55 GMT

GPP wave-1: alias redirect to Initialization Protocol

New page

#REDIRECT [[Initialization Protocol]]

L-doc

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:40:20 GMT

GPP wave-1: alias redirect to Learning Document

New page

#REDIRECT [[Learning Document]]

Verification Test

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:39:44 GMT

GPP wave-1: create Verification Test (AGET dual-surface publication)

New page

A '''Verification Test''' (V-test) is an executable check paired with a requirement or deliverable that returns pass or fail, distinguishing verified completion from declared completion.
* AKA: V-Test.
* Context:
** It can gate stage boundaries: work is complete when its test passes, not when its author asserts completion.
** It can be paired one-to-one with a requirement identifier in a [[Software_Specification|specification]], giving each contract clause an executable falsifier.
** It can be distinguished from a general [[Software_Test]] by its governance role: it verifies that a claimed deliverable exists and behaves as claimed, rather than exploring behavior generally.
** It can counter completion-declaration bias in both human and [[Software Agent|agent]] workflows.
* Example(s):
** A release gate requires each advertised capability to pass its verification test — an executable command whose output confirms the artifact exists and behaves as claimed — before the release tag is created.
** An [[Acceptance_Test]] tied to a contract clause in a formal requirements document.
* Counter-Example(s):
** An exploratory [[Unit_Test]] suite — verifies code behavior, not deliverable-against-claim.
** A manual review checklist without an executable check — declaration, not verification.
* See: [[Software_Test]], [[Acceptance_Test]], [[Software_Specification]], [[Requirement]], [[Quality_Gate]], [[Test-Driven_Development]].
----
== References ==
* Published from the [https://github.com/aget-framework AGET framework]; machine-readable concept: [https://w3id.org/aget/vocab#Verification_Test w3id.org/aget/vocab#Verification_Test]

Initialization Protocol

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:39:08 GMT

GPP wave-1: create Initialization Protocol (AGET dual-surface publication)

New page

An '''Initialization Protocol''' is a defined startup [[Protocol|protocol]] that loads a [[Software Agent|software agent]]'s identity, version, governing constraints, and pending work into operating context before substantive work begins.
* AKA: Wake-Up Protocol, Session Initialization.
* Context:
** It can ensure each operating interval starts from verified state rather than assumptions.
** It can be paired with a counterpart termination protocol that performs structured closure and handoff at the end of a [[Software Session]].
** It can be implemented as an executable script plus an extension hook, so canonical behavior and instance-specific behavior stay separable.
** It can surface pending work, health warnings, and governance state as its output — a briefing, not just a boot.
* Example(s):
** On "wake up", an agent runs its initialization protocol: read identity and version, verify governance is loaded, list active work, report readiness.
** An [[Operating_System]] boot sequence that verifies integrity before accepting user work — the same shape at a lower layer.
* Counter-Example(s):
** Lazy on-demand context loading — no defined ritual, no verified starting state.
** A [[Configuration_File]] read at import time — configuration without verification or briefing.
* See: [[Protocol]], [[Session_Protocol]], [[Software Session]], [[Bootstrapping]], [[Software Agent]], [[Runbook]].
----
== References ==
* Published from the [https://github.com/aget-framework AGET framework]; machine-readable concept: [https://w3id.org/aget/vocab#Initialization_Protocol w3id.org/aget/vocab#Initialization_Protocol]

Software Session

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:38:32 GMT

GPP wave-1: create Software Session (AGET dual-surface publication)

New page

A '''Software Session''' is a bounded interval of interactive or autonomous software operation with a defined start and end, its own working context, and lifecycle protocols that establish and wind down that context.
* AKA: Agent Session, Work Session.
* Context:
** It can be the unit within which context is loaded, work is performed, and durable artifacts are handed off — particularly for collaborative [[Software Agent|software agents]].
** It can be governed by [[Session_Protocol|session protocols]]: an [[Initialization Protocol]] at open, checkpointing during, and a termination protocol at close.
** It can persist state across its boundary via handoff artifacts, distinguishing it from a stateless request/response exchange.
** It can be measured (duration, outcomes, cost) as an operational unit.
* Example(s):
** An agent session opens with an initialization protocol that loads identity and pending work, and closes by writing a handoff file for the next session.
** A [[Login_Session|login session]] on a multi-user system; an interactive [[REPL]] session with persistent workspace state.
* Counter-Example(s):
** A single stateless [[API]] request — no established working context, no lifecycle.
** A continuously-running [[Daemon_Process|daemon]] — no bounded start/end tied to a unit of work.
* See: [[Session_Protocol]], [[Initialization Protocol]], [[Process]], [[Workflow]], [[Learning Document]], [[State]].
----
== References ==
* Published from the [https://github.com/aget-framework AGET framework]; machine-readable concept: [https://w3id.org/aget/vocab#Software_Session w3id.org/aget/vocab#Software_Session]

Agent Fleet

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:37:56 GMT

GPP wave-1: create Agent Fleet (AGET dual-surface publication)

New page

An '''Agent Fleet''' is a bounded set of [[Software Agent|software agents]] operating under shared governance, typically with one supervising agent and multiple worker agents.
* Context:
** It can share configuration standards, [[Session_Protocol|session protocols]], and a common upgrade lifecycle, while each member retains its own domain scope and memory.
** It can be coordinated by a supervising agent that holds oversight capability — supervision being a capability of a member, not a separate agent type.
** It can range from a small personal fleet to an organizational [[Multi-Agent_System]].
** It can be distinguished from an ad-hoc collection of agents by its shared governance and lifecycle.
* Example(s):
** A fleet supervisor coordinates version upgrades across its worker agents and verifies each member's deployment before closing a release cycle.
** A personal fleet in which one agent manages a public repository while siblings manage infrastructure and content, under one principal.
** [[Fleet (AGET)]] — the AGET framework's instantiation of this concept.
* Counter-Example(s):
** A [[Multi-Agent_System]] of independently-owned agents with no shared governance or upgrade lifecycle.
** A load-balanced pool of identical stateless service instances — replicas, not governed members with distinct scopes.
* See: [[Multi-Agent_System]], [[Software Agent]], [[Agent-Based_System]], [[Fleet (AGET)]], [[Initialization Protocol]], [[System_Governance]].
----
== References ==
* Published from the [https://github.com/aget-framework AGET framework]; machine-readable concept: [https://w3id.org/aget/vocab#Agent_Fleet w3id.org/aget/vocab#Agent_Fleet]

Learning Document

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:37:21 GMT

GPP wave-1: create Learning Document (AGET dual-surface publication)

New page

A '''Learning Document''' (also: lesson-learned document, L-doc) is a [[Document]] that captures a single, durable learning extracted from operational experience for later reference and reuse.
* AKA: L-doc, Lesson-Learned Document.
* Context:
** It can function as a unit of [[organizational memory]] persisting beyond ephemeral session context.
** It can bridge [[tacit knowledge]] (lived experience) and [[explicit knowledge]] ([[Knowledge_Base|knowledge-base]]-storable form).
** It can be designed for accretion: many small documents indexed and cross-linked rather than monolithic reports.
** It can be distinguished from a [[Post-Mortem]] (incident-scoped, multi-finding) and a [[Research_Paper]] (external-audience, evidence-comprehensive).
** It can be characterized by: atomicity (one document captures one learning), stable identification (citable from other artifacts), provenance (originating context recorded), and an explicit status lifecycle (Draft → Active → Superseded or Archived).
* Example(s):
** The AGET framework's evolution files (on the order of 1,000 documents as of 2026) — each capturing one operational learning from human-AI collaborative coding sessions.
** Engineering postmortem follow-up files when split into atomic learnings per finding.
* Counter-Example(s):
** A [[Post-Mortem]] covering multiple findings from one incident — multi-learning by design.
** A [[Status_Report]] — present-state-oriented, not learning-extraction-oriented.
** An [[Architecture_Decision_Record]] — captures a decision and rationale, not a learning extracted from outcomes.
* See: [[Document]], [[Knowledge_Base]], [[Organizational_Learning]], [[Lessons_Learned]], [[Software Session]].
----
== References ==
* Published from the [https://github.com/aget-framework AGET framework]; machine-readable concept: [https://w3id.org/aget/vocab#Learning_Document w3id.org/aget/vocab#Learning_Document]

User:Gmelli-bot-202505/Sandbox

Gmelli-bot-202505 — Sun, 19 Jul 2026 07:19:48 GMT

GPP G3 instrumented sandbox write (reversible)

New page

GPP G3 instrumented sandbox write — 2026-07-19T07:19:42.273323+00:00 — reversible test marker.