Pith. sign in

REVIEW 4 major objections 6 minor 29 references

HyperGraphOS: A Meta Operating System for Science and Engineering

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read HyperGraphOS claims that a browser-based workspace where every model is both a visual graph and a JSON data structure, steered by user-defined domain-specific languages, can serve as an operating system for science and engineering and can…

desk verdict A real graph-DSL platform with a genuine artifact, but the paper's central flexibility claims are anecdotal and the model-data duality is undercut by its own template-based generation description. read the letter →

arxiv 2412.04923 v1 pith:SVQLJZIJ submitted 2024-12-06 cs.AI cs.MA

Antonello Ceravola , Frank Joublin , Ahmed R. Sadik , Bram Bolder , Juha-Pekka Tolvanen This is my paper · ORCID
classification cs.AIcs.MA
keywords HyperGraphOSmodelingdomain-specificlanguagesmodel-basedengineeringcodegenerationmetaoperatingsystemAIintegrationJSONworkspace
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is trying to establish that an operating system for science and engineering can be built out of graphs instead of files and folders. In HyperGraphOS, every workspace is an infinite "OmniSpace" whose nodes and links are both a visual drawing and a JSON object, and users can define domain-specific languages that drive navigation, code generation, AI integration, and process management. If the claim is right, scientists and engineers could organize knowledge, documents, and executable applications in one browser-based environment, replacing the file/folder metaphor with directly manipulable models. The paper supports the claim with three case studies, the largest being a virtual receptionist dialog model with 4,246 nodes that generates JavaScript code in under three seconds.

What carries the argument

The load-bearing object is the OmniSpace, an infinite graph workspace whose nodes and links are simultaneously visual drawings and JSON data structures. Around it sits the DSL layer: built-in DSLs for navigation, data flow, execution, user interfaces, animation, and multi-agent systems, plus Meta-DSLs that let users define new DSLs, including a meta-meta-model for defining DSLs themselves. Code generation is carried out by template engines that turn example files into annotated templates and map graph nodes to generated JavaScript files, while a JavaScript shell and APIs allow programmatic manipulation of the same model. The mechanism being demonstrated is that modeling, data storage, and execution can all live in the same graph object, so a user-editable model is also the executable application.

What would settle it

Rebuild the avatar receptionist dialog model using only the published JSON workspace, the annotated templates, and the generator models, then run the generated JavaScript in the avatar engine without modifying any hand-written code; if the application's behavior cannot be reproduced, the central claim that the graph model is a complete executable description would be refuted.

Watch

Extended reading notes

Core claim

On its own terms, the paper claims that HyperGraphOS is a web-based meta operating system in which every workspace is a graph that is simultaneously a visual drawing and a JSON data structure. Domain-specific languages, either built-in or defined by users through recursive meta-DSLs, drive navigation, code generation, AI assistance, and process organization, and template-based generators map graph nodes to executable JavaScript output. The central discovery is the dual nature of models: the same graph object serves as the visual interface, the data store, and the executable specification. In the main case study, a 4,246-node dialog model with 3,890 links generates JavaScript dictionaries, recurrent-network weights, and NLP intents totaling thousands of lines in under three seconds, and the paper reports building the DSL in about three days and the code generator in about one week.

Load-bearing premise

The demonstration rests on the premise that a graph model saved as JSON, together with template-based generators, completely describes the executable application, so the claimed flexibility and model-data duality would fail if essential behavior lives in the hand-written templates or in the DSL tooling rather than in the user-editable graph.

Editorial extensions

If this is right

  • If HyperGraphOS is right, file and folder management can be replaced by graph-based models where a node represents a file, part of a file, or a group of files, with visible links replacing naming conventions.
  • A DSL for a new application domain can be created in days and a code generator in about a week, making rapid prototyping and iterative redesign practical for research projects.
  • The same graph model can be executed in place, run in batch, or deployed to a target computer, so design, implementation, and analysis artifacts are one object rather than separate files.
  • Large language models and other AI tools can be integrated into the modeling and code-generation loop, offering on-demand assistance, content creation, and programmatic manipulation of models.
  • The open-source availability of HyperGraphOS means other teams can build and test their own DSLs without writing an operating system from scratch.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper does not test this, but the graph-as-JSON mechanism could make full reproducibility practical: versioning the JSON workspace together with the templates would let a third party regenerate the exact executable application.
  • The paper does not quantify it, but the OmniSpace state-restoration feature could eliminate the desktop-layout and context-switching overhead identified in Section 2, a testable usability claim.
  • The reported development-time reductions are anecdotal; a controlled replication by an independent team would establish whether the speedup comes from the platform or from the developers' prior expertise.
  • The recursive meta-DSL design implies that domain experts could define executable languages without conventional programming, a claim that could be tested with non-programmer scientists building a small DSL from scratch.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. HyperGraphOS is presented as a web-based graph-modeling platform that combines model-based engineering, graph representations, DSLs, JSON-based workspaces, code generation, and AI integration. The paper describes the system architecture and reports three case studies: multi-agent robotic task planning (CoPAL), research-project modeling with the Thebes DSL, and a virtual receptionist dialog system. The stated central claim is that the platform yields significant improvements in flexibility, data management, computation, and document handling, supported by development-time anecdotes and a 4246-node dialog model that generates JavaScript artifacts in under three seconds.

Significance. The system is open-source and the case studies involve nontrivial, concrete artifacts, including a 4246-node dialog model and generated dictionary, weight, and intent files; this gives the paper value as a tool/experience report. However, the central claim of significant improvement is not established: there are no controlled comparisons, no baselines, no user studies, and the model-data duality is only partially demonstrated. The paper is best read as a description of a platform with illustrative applications; its significance for the claimed generality is conditional on additional evaluation.

major comments (4)
  1. [§5.3, Figs. 8-9] The claimed model-data duality (§4) is undercut by the code-generation description. The template is created by manually annotating a target example file (Fig. 8), and the generation logic is defined as a separate model implemented in JavaScript (Fig. 9). The graph model supplies parameter values such as dictionaries, weights, and intents, but the output language's syntax, control flow, and semantics live in the templates and generator code. The paper never demonstrates that a structural change to the graph, such as adding a new action type or grammar construct, regenerates correct executable behavior without editing templates or generator code. Please provide such a demonstration, or explicitly scope the flexibility claim to parameter-level variation.
  2. [Abstract, §5, §6.2] The central claim of 'significant improvements in flexibility, data management, computation, and document handling' is not supported by controlled measurements. The development-time statements (DSL in 3 days, code generator in 1 week, Thebes metamodel in 30 minutes and integrity checkers in 3 days, CoPAL DSL in 1 week) are anecdotal, with no task definitions, no comparison against alternative tools or methods, and no variance estimates. Add a systematic evaluation with defined tasks and baselines, or rewrite the claims as qualitative experience-report statements.
  3. [§6.1] The comparison with PlantUML, Graphviz, MetaEdit+, JetBrains MPS, and Eclipse Xtext asserts that HyperGraphOS is 'more intuitive and accessible' and 'more flexible,' but no evaluation against these tools is provided. Since the paper's significance depends on superiority over existing DSL and graph tools, either report a criteria-based comparative evaluation, such as task completion time, number of steps, or learning curve, or soften these claims to capability descriptions.
  4. [§5, Case Study 3] The code-generation performance figure (average less than 3 seconds for the 4246-node model) is given without measurement details, such as number of runs, variance, hardware state, or breakdown by generated file type. Because computation is one of the four claimed improvement areas, report the measurement protocol and raw statistics for reproducibility.
minor comments (6)
  1. [§6.3 vs. §3, §6.2] Section 6.3 states that HyperGraphOS 'will soon become an open-source project,' while Sections 3 and 6.2 state that it is already available at repository [11]; please reconcile this contradiction.
  2. [Keywords] The keyword list includes 'Cyclomatic Complexity,' but the text never defines or uses this concept; either add a discussion of its relevance or remove the keyword.
  3. [§4, Scalability paragraph] The text contains the typo 'OmnisSpaces' in the scalability paragraph; elsewhere the spelling is 'OmniSpaces.'
  4. [§4] The paper says each workspace is stored as a JSON object, but the same section mentions YAML for some DSLs; clarify how YAML fits into the dual-representation claim.
  5. [§5, Case Studies 1 and 2] The development-time statements ('single week,' '30 minutes,' 'three days') lack scope definitions; specify what activities are included and excluded so that readers can interpret the figures.
  6. [References, §3 and §6.2] Reference [12] is cited for core HyperGraphOS concept claims, but it is a documentation video URL; consider citing an archival or peer-reviewed description of the system if one exists.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: HyperGraphOS is a tool-presentation paper whose claims rest on original case-study demonstrations, not on derivations that reduce to their own inputs.

full rationale

The paper contains no equations, no fitted parameters, and no formal predictions, so the equation-level circularity patterns (self-definitional reduction, fitted input called prediction) do not apply. The central claims—that HyperGraphOS offers a graph-based, DSL-driven workspace with dual visual/data representations and facilitates code generation—are supported by three case studies, including a 4246-node dialog model that generates JavaScript dictionaries, weights, and NLP intents. These are original demonstrations of the tool being used, not quantities derived from the tool's own assumptions. The self-citations present in the paper ([12], [14], [15], [21], [22], [28]) are normal author references to prior related work and documentation; none is invoked as a uniqueness theorem, a proof of correctness, or an external validation that the paper's conclusions are forced. The claim that AI-powered modeling enhances productivity cites the authors' prior work, but this claim is peripheral to the main contribution and is not used to define or derive the platform's capabilities. The skeptic's concern that essential behavior resides in templates and generator code rather than in the user-editable graph is a legitimate evidence/validity question about the strength of the model-driven claim, but it is not circularity: the paper does not define the graph model in terms of the generated output, nor does it fit any parameter to the case-study results and then call that a prediction. Overall, the derivation chain is self-contained as a systems/experience report; any weaknesses are about evidence strength and generalizability, not circular reasoning.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

No new physical or mathematical entities are postulated. HyperGraphOS, OmniSpace, Miron, and Thebes are implemented software artifacts, not unexplained postulated entities, and the open-source repository provides an external falsifiable handle. The main unstated assumptions concern the completeness of the JSON graph representation and the causal role of the tool in the reported productivity gains.

assumptions (3)
  • domain assumption A graph model serialized as JSON captures all information needed to regenerate executable application code.
    Invoked in Section 4 where workspaces are stored as JSON objects and in Section 5 where templates generate JavaScript files from graph models. If semantics leak into hand-written templates, the model-driven flexibility claim is weakened.
  • domain assumption Domain-specific languages defined through HyperGraphOS's meta-meta-model are expressive enough to represent the target application domains, such as robotics, dialogue, and research projects.
    The case studies in Section 5 assume that the Miron and Dialog DSL abstractions capture dialog behavior and neural-network weights.
  • domain assumption LLM-assisted modeling improves productivity, as reflected in the reported development times of days or weeks.
    This relies on the authors' prior work [21] and on qualitative case-study statements rather than on an independent controlled measurement.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HyperGraphOS: A Meta Operating System for Science and Engineering." pith.science (2026). https://pith.science/paper/SVQLJZIJ

@misc{pith2026241204923,
  author       = {Pith},
  title        = {Pith review of: HyperGraphOS: A Meta Operating System for Science and Engineering},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SVQLJZIJ}},
  note         = {Machine review of arXiv:2412.04923}
}
read the original abstract

This paper presents HyperGraphOS, an innovative Operating System designed for the scientific and engineering domains. It combines model based engineering, graph modeling, data containers, and computational tools, offering users a dynamic workspace for creating and managing complex models represented as customizable graphs. Using a web based architecture, HyperGraphOS requires only a modern browser to organize knowledge, documents, and content into interconnected models. Domain Specific Languages drive workspace navigation, code generation, AI integration, and process organization.The platform models function as both visual drawings and data structures, enabling dynamic modifications and inspection, both interactively and programmatically. HyperGraphOS was evaluated across various domains, including virtual avatars, robotic task planning using Large Language Models, and meta modeling for feature based code development. Results show significant improvements in flexibility, data management, computation, and document handling.

Figures

Figures reproduced from arXiv: 2412.04923 by the authors.

Figure 1
Figure 1. Historical Influences leading to the development of HyperGraphOS. on the desktop, have attributes like names, sizes, and creation dates, while windows display application content and include attributes such as size, position, and title. This abstraction simplifies user interaction by hiding the underlying complexity. However, traditional DSLs come with several limitations. Desktops introduced in the 1970s followed a… view at source ↗
Figure 2
Figure 2. a) HyperGraphOS operation concept. b) Basic DSL for navigation and file manipulation The operation concept of HyperGraphOS shown in Fig. 2a transforms traditional file management into an inter￾connected web of information. Nodes within the system represent files, documents, and data, which are customizable, annotatable, and maintainable. These nodes visually link data while encapsulating both content and visual aspe… view at source ↗
Figure 3
Figure 3. HyperGraphOS Landing Workspace (https://youtu.be/xjoj-snEV_o) [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: HyperGraphOS software architecture platform supports model-based system engineering and development, assisting in overcoming limitations of traditional OSs. 4 SYSTEM ARCHITECTURE HyperGraphOS is built on a modular architecture as shown in [PITH_FULL_IMAGE:figures/full…
Figure 5
Figure 5. Figure 5: Rule DSL Elements : A) Graphical representation of a rule defined by its auto-generated ID (107), its conditions and its actions. The gray box is just a comment used to explain the rule. B) Possible state of a Miron (an abstraction used to equally recognize and generat…
Figure 6
Figure 6. Figure 6: Miron DSL elements: A) Graphical representation of a Miron defined by a modality, a name, a type (inner or outer), templates, named entities (slots) and associated data (data slots). B) Example of different Miron modalities. Modalities were used to control speech outpu…
Figure 7
Figure 7. Figure 7: Avatar Receptionist Network Modeling Process To illustrate the development of a DSL and the process of code generation in HyperGraphOS, this case study focuses on the creation of the Dialog DSL ( [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Example of Avatar Dialog Network source template. Comments like ’//[# command #] represent code generation commands, while comments like ’//: ...’ represent command parameters [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: Code generation model for the Dialog Model [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 10
Figure 10. Figure 10: View of the full Dialog Model for the Avatar Receptionist. The code generation model shown in figure 9 is in the center top of this model [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 26 canonical work pages

  1. [1]

    Atlassian: Workflow automation in agile project management.https://www.atlassian.com/agile/project-management/ workflow-automation (2024), accessed: 22-Sep-2024

    work page 2024

  2. [2]

    Computer20(4), 10–19 (1987)

    Brooks, F.P.: No silver bullet: Essence and accident of software engineering. Computer20(4), 10–19 (1987)

    work page 1987

  3. [3]

    Reflections on programming systems: Historical and philosophical aspects pp

    Bullynck, M.: What is an operating system? a historical investigation (1954–1964). Reflections on programming systems: Historical and philosophical aspects pp. 49–79 (2018)

    work page 2018

  4. [4]

    Software and Systems Modeling22(3), 781–793 (2023)

    Camara, J., Troya, J., Burgueno, L., Vallecillo, A.: On the assessment of generative ai in modeling tasks: An experience report with chatgpt and uml. Software and Systems Modeling22(3), 781–793 (2023)

    work page 2023

  5. [5]

    Towards Living Software Architecture Diagrams

    Correia, F.F., Ferreira, R., Queiroz, P.G., Nunes, H., Barra, M., Figueiredo, D.: Towards living software architecture diagrams. arXiv preprint arXiv:2407.17990 (2024)

    work page Pith review arXiv 2024

  6. [6]

    Software and Systems Modeling 22(1), 415–447 (2023).https://doi.org/10.1007/s10270-022-01010-3

    David, I., Latifaj, M., Pietron, J., Zhang, W., Ciccozzi, F., Malavolta, I., Raschke, A., Steghofer, J., Hebig, R.: Blended modeling in commercial and open-source model-driven software engineering tools: A systematic study. Software and Systems Modeling 22(1), 415–447 (2023).https://doi.org/10.1007/s10270-022-01010-3

    doi:10.1007/s10270-022-01010-3 2023

  7. [7]

    The School of Computer Science and Engineering Royal Institute of Technology pp

    Eriksson, M., Hallberg, V.: Comparison between json and yaml for data serialization. The School of Computer Science and Engineering Royal Institute of Technology pp. 1–25 (2011)

    work page 2011

  8. [8]

    Technical report, AT&T Bell Laboratories, Murray, Tech

    Gansner, E.R.: Drawing graphs with graphviz. Technical report, AT&T Bell Laboratories, Murray, Tech. Rep, Tech. Rep. (2009)

    work page 2009

Show all 29 references
  1. [9]

    In: Proceedings of the 2018 ACM/IEEE international conference on human-robot interaction

    Gomez, R., Szapiro, D., Galindo, K., Nakamura, K.: Haru: Hardware design of an experimental tabletop robot assistant. In: Proceedings of the 2018 ACM/IEEE international conference on human-robot interaction. pp. 233–240 (2018)

    2018

  2. [10]

    In: MoDELS (Doctoral Symposium) (2014)

    Herrera, A.S.B.: Enhancing xtext for general purpose languages. In: MoDELS (Doctoral Symposium) (2014)

    2014

  3. [11]

    https://github.com/HRI-EU/hypergraphos (2024), accessed: 21-Oct-2024

    HRI-EU: Hypergraphos. https://github.com/HRI-EU/hypergraphos (2024), accessed: 21-Oct-2024

    2024

  4. [12]

    https://github.com/HRI-EU/hypergraphos/tree/main/Documentation/Videos (2024), accessed: 22-Oct-2024

    HRI-EU: Hypergraphos-documentation. https://github.com/HRI-EU/hypergraphos/tree/main/Documentation/Videos (2024), accessed: 22-Oct-2024

    2024

  5. [13]

    Inc., A.: Automator user guide for macos.https://support.apple.com/guide/automator/welcome/mac (2024), accessed: 22-Sep-2024

    2024

  6. [14]

    arXiv preprint arXiv:2406.08996 (2024)

    Joublin, F., Ceravola, A., Sandu, C.: Introducing brain-like concepts to embodied hand-crafted dialog management system. arXiv preprint arXiv:2406.08996 (2024)

    2024 arXiv

  7. [15]

    In: 2024 IEEE International Conference on Robotics and Automation (ICRA)

    Joublin, F., Ceravola, A., Smirnov, P., Ocker, F., Deigmoeller, J., Belardinelli, A., Wang, C., Hasler, S., Tanneberg, D., Gienger, M.: Copal: corrective planning of robot actions with large language models. In: 2024 IEEE International Conference on Robotics and Automation (IC...

    2024

  8. [16]

    Microsoft: Powertoys for windows.https://learn.microsoft.com/en-us/windows/powertoys/ (2024), accessed: 22-Sep- 2024

    2024

  9. [17]

    Northwoods: Gojs: Powerful diagrams for every industry.https://gojs.net/latest/index.html (2022), accessed: Septem- ber 2024

    2022

  10. [18]

    Caine 9, 157–162 (2009)

    Nurseitov, N., Paulson, M., Reynolds, R., Izurieta, C.: Comparison of json and xml data interchange formats: a case study. Caine 9, 157–162 (2009)

    2009

  11. [19]

    In: Proceedings of the 2013 International Conference on Principles and Practices of Programming on the Java Platform: Virtual Machines, Languages, and Tools

    Pech, V., Shatalin, A., Voelter, M.: Jetbrains mps as a tool for extending java. In: Proceedings of the 2013 International Conference on Principles and Practices of Programming on the Java Platform: Virtual Machines, Languages, and Tools. pp. 165–168 (2013)

    2013

  12. [20]

    In: ICRA workshop on open source software

    Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T., Leibs, J., Wheeler, R., Ng, A.Y., et al.: Ros: an open-source robot operating system. In: ICRA workshop on open source software. vol. 3, p. 5. Kobe, Japan (2009)

    2009

  13. [21]

    In: The Interna- tional Conference on Model-Based Software and Systems Engineering - MODELSWARD 2024

    Sadik, A.R., Brulin, S., Olhofer, M.: Coding by design: Gpt-4 empowers agile model driven development. In: The Interna- tional Conference on Model-Based Software and Systems Engineering - MODELSWARD 2024. pp. 149–156 (2024)

    2024

  14. [22]

    arXiv preprint arXiv:2306.00597 (2023)

    Sadik, A.R., Ceravola, A., Joublin, F., Patra, J.: Analysis of chatgpt on source code. arXiv preprint arXiv:2306.00597 (2023)

    2023 arXiv

  15. [23]

    Wiley Publishing (2013)

    Silberschatz, A., Galvin, P.B., Gagne, G.: Operating system concepts essentials. Wiley Publishing (2013)

    2013

  16. [24]

    Pearson Education, Inc., (2009)

    Tanenbaum, A.: Modern operating systems. Pearson Education, Inc., (2009)

    2009

  17. [25]

    Technology, R.: Rabbit r1 - ai-powered personal assistant.https://www.rabbit.tech/rabbit-r1 (2024), accessed: 22-Sep- 2024

    2024

  18. [26]

    Thunkable, I.: Thunkable - no code app builder.https://thunkable.com/ (2024), accessed: 22-Sep-2024

    2024

  19. [27]

    Tolvanen, J.P., Kelly, S.: Model-driven development challenges and solutions: Experiences with domain-specific modelling in industry.In:20164thInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment(MODELSWARD). pp. 711–719. IEEE (2016)

    2016

  20. [28]

    In: 2023 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)

    Tolvanen, J.P., Kelly, S.: Evaluating tool support for co-evolution of modeling languages, tools and models. In: 2023 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). pp. 914–923. IEEE (2023)

    2023

  21. [29]

    IJCSN International Journal of Computer Science and Network3(4), 257–261 (2014)

    Zunke, S., D’Souza, V.: Json vs xml: A comparative performance analysis of data exchange formats. IJCSN International Journal of Computer Science and Network3(4), 257–261 (2014)

    2014

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.