KaOS: Diverse Technical Constructs
- KaOS is a polysemous term that designates distinct technical systems in fields such as multi-agent OS, magnetic spectrometry, requirements engineering, and smart building automation.
- In its multi-agent OS form, KAOS uses large-model agents under an open-source platform to enhance resource scheduling and user experience in complex application environments.
- In engineering contexts, KAOS supports formal goal modeling and distributed control, enabling robust system specifications and containerized smart building automation.
In the arXiv literature represented here, KaOS/KAOS/Kaos is not a single canonical artifact but a label applied to several unrelated technical constructs. The most recent usage in the supplied corpus is "KAOS: Large Model Multi-Agent Operating System", which proposes a multi-agent operating system based on open-source Kylin for large-model-driven applications and shared-resource coordination (Zhuo et al., 2024). The same name also denotes a magnetic spectrometer central to strangeness electroproduction at MAMI (Achenbach, 2011), a goal-oriented requirements engineering tradition and its SysML/Event-B/B-System extensions (Tueno et al., 2017, Fotso et al., 2018), and a distributed smart-building control platform based on containerisation and managed resource access (Skrivankova et al., 7 Sep 2025).
1. Terminological scope and principal referents
The term is best understood as a polysemous technical designation whose meaning depends entirely on disciplinary context. In the supplied literature, the following usages are attested.
| Designation | Domain | Representative characterization |
|---|---|---|
| KAOS | Multi-agent operating systems | A multi-agent operating system based on the open-source Kylin, using large models for applications and shared-resource scheduling |
| Kaos / KaOS | Experimental nuclear and hadronic physics | A compact magnetic spectrometer at MAMI used in strangeness electroproduction |
| KAOS / SysML/KAOS | Requirements engineering and formal methods | A goal-oriented requirements engineering method with goals, agents, domain properties, and formal refinements |
| KaOS | Smart building automation | A distributed control platform for robust and evolvable building automation using containerised control tasks |
This multiplicity matters methodologically. A citation to “KAOS” in requirements engineering usually concerns goal models, formal semantics, and refinement; a citation to “Kaos” in Mainz strangeness physics concerns magnetic spectrometry, missing-mass reconstruction, and forward-angle kaon detection; and a citation to “KaOS” in recent systems work concerns either multi-agent operating systems or distributed IoT control platforms.
2. KAOS as a large model multi-agent operating system
The 2024 paper "KAOS: Large Model Multi-Agent Operating System" defines KAOS as a response to two coupled problems: the need to maintain a uniform user experience across different foundational software platforms and the difficulty of multi-agent collaboration and resource sharing in large-model-based interaction systems (Zhuo et al., 2024). The proposed system is described as a multi-agent operating system based on the open-source Kylin.
Its stated research method has three components. First, it empowers agents with large models to serve applications, introducing management role agents and vertical multi-agent collaboration to construct or replace typical application software. Second, it studies system-level shared resource scheduling strategies intended to enhance user experience and optimize resource utilization. Third, it validates the system through real applications and scoring intelligence, with the paper claiming that the feasibility of the approach is demonstrated and that experimental results show significant advantages of multi-agent collaboration in various application scenarios (Zhuo et al., 2024).
The evidentiary status of this usage is unusually constrained. In the supplied record, no PDF/source was available for version v3, so the recoverable scientific content is limited to the abstract and bibliographic metadata. Accordingly, finer claims about scheduler design, agent interfaces, evaluation metrics, baselines, algorithms, or quantitative gains are not available from the supplied evidence. This suggests that the present state of documentation, at least in the supplied material, supports an architectural overview rather than a full technical reconstruction.
3. Kaos as a magnetic spectrometer at MAMI
In experimental strangeness physics, Kaos is a compact magnetic spectrometer operated by the A1 collaboration at the Mainz Microtron MAMI for reactions on the proton and light nuclei (Achenbach, 2011). Its importance derives from a specific combination of properties: compact geometry, operation at very forward scattering angles, and the capability to detect positive and negative charged particles simultaneously. These characteristics complement the larger A1 spectrometers and make Kaos particularly suitable for low- kaon electroproduction and hypernuclear studies.
The instrument was used in pilot kaon electroproduction measurements on a liquid hydrogen target with a 1.508 GeV electron beam, covering average momentum transfers of and . In those measurements, associated and hyperons were identified in missing-mass spectra, demonstrating that the MAMI facility could perform strangeness electroproduction spectroscopy in this low- regime (Achenbach, 2011). A later report emphasizes sensitivity to phenomenological modeling at low four-momentum transfer, particularly in comparisons between Kaon-Maid and Saclay-Lyon A at forward angles and moderate (Achenbach, 2012).
Kaos also became the focus of substantial detector and DAQ development. For zero-degree double-arm operation, the program introduced a magnetic chicane comprising two compensating sector magnets and a new electron-arm focal-plane detector system. The detector was built around two vertical planes and 18,432 fibres, with electronics for 4,608 read-out and level-1 trigger channels (Achenbach, 2012). A dedicated large-scale FPGA-based trigger and nearly dead-time-free DAQ system was designed for the electron arm, processing more than 4,000 read-out channels and implementing noise suppression, signal cluster finding, particle tracking, and coincidence timing under severe forward-angle background conditions (Achenbach et al., 2011).
Taken together, these papers establish Kaos as both an instrument and an instrumentation program: a spectrometer supporting low- open-strangeness measurements, and a platform around which fibre detectors, SiPM-based tracking concepts, and high-rate trigger/DAQ architectures were developed.
4. KAOS as a goal-oriented requirements engineering method
In requirements engineering, KAOS denotes a formal Goal-Oriented Requirements Engineering method. In the supplied literature it is described as modeling goals as prescriptive statements of intent, agents as active entities responsible for satisfying goals, domain properties as statements about the environment, and refinement links between goals (Alrajeh et al., 9 Jan 2026). One educational paper expands the acronym as “Knowledge Acquisition in autOmated Specification” and also records the alternative expansion “Keep All Objects Satisfied” (Batista et al., 2024).
A central formal development appears in "The SysML/KAOS Domain Modeling Approach", where SysML/KAOS is presented as an extension of KAOS in which the formal semantics of SysML/KAOS goals are represented using Event-B specifications (Tueno et al., 2017). In this formulation, goals provide the set of events, while domain models provide the structure of the system state. The approach adds an ontology-inspired domain modeling formalism, drawing on OWL and PLIB, and favors a closed-world assumption with strong typing and the Unique Name Assumption. It also treats refinement explicitly: each level of the goal hierarchy is associated with a corresponding domain model, and a functional goal is semantically expressed as “[if CurrentCondition then] sooner-or-later TargetCondition” (Tueno et al., 2017).
This formalization was extended toward proof-oriented specification in "SysML/KAOS Domain Models and B System Specifications", which combines the SysML/KAOS requirements engineering method, concepts of the KAOS goal model, and the B System formal method (Fotso et al., 2018). That paper states that translation rules from a SysML/KAOS goal model to a B System specification have been defined to produce a skeleton specification, and that the translation of the associated domain model yields the structural part of the B System specification. It further reports formal verification of these rules, an open source tool, and case-study use on the hybrid ERTMS/ETCS level 3 standard (Fotso et al., 2018).
Within this lineage, KAOS is not merely a diagrammatic notation. It is a requirements formalism aimed at preserving traceability from strategic goals to operational requirements, while enabling consistency checking against domain properties and, in some variants, formal verification in Event-B or B.
5. Extensions of KAOS in AI, ML, and resilience engineering
Recent work applies KAOS to domains in which deterministic operationalization is inadequate. In ML-enabled law enforcement systems, KAOS was used to structure goal elaboration, object modeling, agent assignment, and operationalization for suspect identification in online child sexual abuse investigations (Alrajeh et al., 9 Jan 2026). The study began with semi-structured interviews with 11 investigators, identified 557 unique goals, classified them into 499 functional and 58 non-functional goals, and extracted 203 environment assumptions. After prioritization, it retained 30 leaf goals for prototype development. The authors then assigned 15 leaf goals to ML agents, 13 to non-ML software, and 2 to LEA investigators, instantiating 15 BERT models and 10 ILP learners. A key finding was that data elicitation had to become a first-class KAOS activity, because data availability, label granularity, and model performance constrained refinement and responsibility assignment (Alrajeh et al., 9 Jan 2026).
In software engineering education for AI, KAOS has been studied as a teaching vehicle for Requirements Engineering for AI-based systems. An empirical classroom study involving 34 undergraduate software engineering students reported that 88% applied KAOS correctly or with minor inadequacies, while 83% rated it as moderately easy or easier to learn (Batista et al., 2024). The same study found KAOS particularly effective for high-level elicitation of User Needs, Model Needs, and Data Needs, but less effective for privacy, explainability, and error handling, with explicit challenges around goal refinement stopping criteria and diagram complexity (Batista et al., 2024).
KAOS has also been adapted to represent resilience requirements in microservice architecture systems. In that work, KAOS is used together with a Microservice Resilience Measurement Model whose central quantitative notion is 0, where 1 is Disruption Tolerance, 2 is Recovery Rapidity, and 3 is Performance Loss (Yin et al., 2019). The requirement model maps resilience goals, obstacles, domain properties, agents, and a new element called Asset to measurable runtime phenomena, then decomposes service resilience goals into resource resilience goals and ultimately into executable system behaviors. This illustrates a broader pattern: KAOS increasingly functions as a bridge between strategic intent and quantitative or probabilistic operationalization.
6. KaOS as a distributed platform for smart building automation
A distinct 2025 usage of the name appears in "20 Years in Life of a Smart Building: A retrospective", where KaOS denotes a distributed control platform for constructing robust and evolvable smart building automation systems using affordable, off-the-shelf IoT hardware (Skrivankova et al., 7 Sep 2025). The platform is designed to support both control applications and distributed system operations by leveraging containerisation and managed resource access, with the explicit goal of achieving flexibility, security, and fault tolerance without sacrificing cost-effectiveness.
The architecture models a building automation deployment as a directed graph of control tasks mapped onto a set of physical devices. Control tasks are encapsulated in WebAssembly containers, which provide a hardware-agnostic compilation target, sandboxed execution, and lightweight isolation. An orchestrator manages lifecycle, placement, privileges, and communication channels, but is not in the critical control loop. Communication is mediated by pre-approved message-passing channels that may be reliable or unreliable and push or pull, rather than by unrestricted container-created networking (Skrivankova et al., 7 Sep 2025).
This platform is explicitly motivated by long-horizon systems concerns: hardware failures, vendor obsolescence, changing building layouts, and evolving cybersecurity threats. The paper reports preliminary tests of a simple control architecture on multiple cooperating ESP-32 devices and states that it measured negligible execution latency added due to container crossing and processing overhead (Skrivankova et al., 7 Sep 2025). It therefore presents KaOS as a distributed-systems answer to decade-scale building automation, rather than as a large-model agent framework or a requirements-engineering method.
7. Comparative significance and interpretive cautions
Across these literatures, the commonality of the name conceals deep heterogeneity of purpose. The 2024 large-model KAOS is concerned with multi-agent collaboration, shared-resource scheduling, and uniform user experience across software platforms (Zhuo et al., 2024). The MAMI Kaos work concerns magnetic spectrometry, forward-angle kaon detection, and missing-mass hyperon spectroscopy (Achenbach, 2011). The requirements-engineering KAOS tradition formalizes goals, agents, domain properties, obstacles, and refinements, and has been extended toward Event-B, B System, ML-enabled systems, and microservice resilience (Tueno et al., 2017, Fotso et al., 2018, Yin et al., 2019, Alrajeh et al., 9 Jan 2026). The smart-building KaOS platform is a distributed control substrate built around containerised tasks and managed channels (Skrivankova et al., 7 Sep 2025).
A plausible implication is that references to “KaOS” should always be interpreted as domain-indexed terminology rather than as a stable proper name. For technical reading, this is not a minor bibliographic issue: the same string may refer to an operating-system architecture, a spectrometer, a formal requirements method, or a distributed building-control platform. In practice, correct interpretation depends on adjacent vocabulary—such as Kylin, MAMI, SysML/KAOS, Event-B, WebAssembly, or smart building automation—rather than on the name alone.
