EngineeringOS Manifesto

Build the open semantic infrastructure for engineering.

Engineering is about to undergo its biggest architectural shift since CAD replaced paper. The next era of engineering software will not be organized around drawings first, file formats first, or vendor applications first. It will be organized around explicit engineering meaning.

Engineering software is still drawing-centric. AI requires semantic engineering.

That is the problem. Everything in this repository exists to respond to it.

The Shift

Paper Era
        ->
CAD Era
        ->
Semantic Engineering Era

For decades, engineering software has treated the drawing or project file as the practical source of truth. That model was good enough when the primary task was document production. It is no longer good enough for machine reasoning, cross-tool continuity, reusable engineering knowledge, or trustworthy AI.

The next shift is from representation to meaning.

Drawing
        ->
Model
        ->
Meaning

What EngineeringOS Is

EngineeringOS is an open semantic engineering platform that separates engineering intent from engineering representation.

Its role is to define a shared layer of Engineering Language, Engineering IR, compiler logic, ontology, rules, and governed knowledge so that engineering meaning can survive outside any one CAD, schematic, or enterprise tool.

Natural Language
        ->
Engineering Language
        ->
Engineering IR
        ->
Compiler
        ->
EPLAN / KiCad / QElectroTech / OpenSCAD / FreeCAD

In this model, downstream tools remain important, but they stop being the deepest source of truth. They become renderers, compatibility targets, and integration surfaces around a more durable semantic core.

What EngineeringOS Is Not

EngineeringOS is not:

another CAD
another EPLAN clone
another electrical editor
another AI wrapper

EngineeringOS is:

an Engineering Language
an Engineering Compiler
an Engineering Knowledge Platform
an open semantic infrastructure

Core Principles

Semantics before drawings.
Open standards before vendor lock-in.
AI augments engineering judgment, not replaces it.
Never reinvent solved problems.
Own the semantic layer.
Everything is pluggable.
Every engineering decision should be traceable.
Human-readable, machine-executable.

Leverage, Don't Replace

EngineeringOS is differentiated not by trying to replace every existing engineering tool, but by standing on top of the strongest ecosystems that already exist.

Geometry: OCCT
PCB: KiCad
Electrical: QElectroTech
Mechanical: FreeCAD
Visualization: OpenUSD
Compiler method: LLVM philosophy

This is a pragmatic architecture, not a purity project. The goal is not to rebuild the whole stack. The goal is to own the missing semantic layer that can coordinate it.

Why This Matters

If engineering meaning can be represented semantically, then rules, standards mappings, ontology packs, templates, validation logic, and domain workflows can become reusable public infrastructure. Engineering knowledge no longer has to die inside isolated projects, PDFs, or proprietary toolchains. It can be versioned, shared, audited, improved, and reused at global scale.

That is why EngineeringOS has the potential to become more than a product. It can become the open infrastructure layer on which future engineering systems are built.

Repository Structure

docs/ contains the manifesto chapters and doctrine.
docs/architecture/ contains the core system design layers.
docs/technologies/ contains reuse strategy and technology decisions.
docs/prd/ contains product-facing documents.
docs/rfc/ contains evolving technical proposals.
docs/references/ contains standards, research, and ecosystem references.

Call To Action

Help build the open semantic infrastructure for engineering.

Reference

Vision

Engineering is about to undergo the biggest architectural shift since CAD replaced paper. The next era of engineering software will not be defined by better drawing tools alone, but by a deeper change in what counts as the source of truth. EngineeringOS exists to define that change clearly enough that others can build on it.

The One-Sentence Problem

Engineering software is still drawing-centric. AI requires semantic engineering.

That sentence is the core of the manifesto. Drawings remain necessary, but they are not a durable foundation for machine reasoning, reusable domain knowledge, trustworthy automation, or cross-tool continuity. If meaning stays trapped inside representation, every downstream capability remains fragile.

The Core Definition

EngineeringOS is an open semantic engineering platform that separates engineering intent from engineering representation.

It does this by defining Engineering Language, Engineering IR, ontology, compiler logic, rules, and governed knowledge as the durable center of the system. Drawings, reports, layouts, and enterprise exports remain necessary outputs, but they become compiled views of a deeper model rather than the place where engineering truth is born.

The Era Shift

The right mental model is not feature evolution. It is era transition.

Paper Era
        ->
CAD Era
        ->
Semantic Engineering Era

The paper era organized engineering around manual documents. The CAD era organized it around digital representation. The semantic era organizes it around explicit engineering meaning that can be written, compiled, validated, shared, and reasoned over across many tools and many domains.

Open Infrastructure, Not One Product

EngineeringOS is intended as infrastructure, not as a single monolithic application. Its role is closer to a compiler substrate or protocol layer than to a conventional editor. Existing systems such as EPLAN, KiCad, QElectroTech, OpenSCAD, FreeCAD, PDF, SVG, MES, and ERP remain important because they become targets, integrations, and compatibility surfaces around the semantic core.

This matters because no one editor or file format can credibly serve as the permanent center of engineering. A shared semantic layer can. That is why the correct comparison is not "better CAD," but something closer to the role LLVM played for compilers: a durable center that many front ends and back ends can use without owning them all.

AI Is Enabled By The Platform, Not The Platform Itself

EngineeringOS should not be framed as an AI project whose value rises and falls with current models. It should be framed as the semantic infrastructure that makes trustworthy engineering AI possible. AI is important because it becomes the first major application unlocked by explicit engineering semantics. It is not the deepest architectural layer.

This distinction makes the vision more durable. Models will change. Semantic contracts, compiler boundaries, ontology governance, and traceable engineering logic can outlast those changes.

What Success Looks Like

Success means engineering intent can survive independently of any single application file. It means the same semantic model can generate many synchronized outputs. It means standards and rules operate on explicit meaning instead of inferred geometry. It means reusable engineering knowledge can accumulate publicly instead of disappearing inside isolated organizations and proprietary workflows.

If that happens, EngineeringOS will matter not only as a repository or a product, but as a movement toward open semantic infrastructure for engineering.

Industry Analysis

Engineering software is still dominated by tool-specific files, domain silos, and vendor-owned data models. Commercial leaders such as EPLAN, Siemens, Autodesk, and Dassault each solve real workflow problems, but they do so inside application boundaries that make semantic portability difficult. Open ecosystems such as KiCad, QElectroTech, FreeCAD, and OpenSCAD prove that communities can build durable engineering tools, yet they also show that a strong editor or renderer is not the same thing as a shared semantic source of truth.

The Incumbent Pattern

The incumbent pattern is consistent across the market. A product owns a file format, a UI model, and a domain-specific workflow, and the user's project becomes increasingly tied to that stack over time. Interoperability exists, but it usually appears as import and export around the edges rather than as a common semantic core that multiple tools can share without loss.

That pattern worked when the primary job of engineering software was document production. It works much less well when engineering systems need machine reasoning, multi-tool synchronization, AI-assisted authoring, governed standards logic, and long-lived interoperability across vendors and domains.

Why Open Source Still Does Not Solve The Core Problem

Open-source engineering tools matter because they provide proven assets, communities, and compatibility surfaces. QElectroTech contributes IEC symbol ecosystems and electrical workflow knowledge. KiCad contributes PCB libraries, file compatibility, and a serious open hardware community. FreeCAD and OCCT contribute mechanical and geometry depth. OpenSCAD contributes the discipline of treating authored code as a design input.

But none of these projects are the missing semantic layer. They are strong products, references, and back ends. The gap remains the same: there is still no open compiler-centered architecture where engineering language, ontology, IR, rules, and governed knowledge become the canonical source of truth above all of those tools.

The Market Gap

The real market gap is not "open-source EPLAN" and not "AI CAD." The gap is a public semantic substrate for engineering. That substrate must be able to express engineering intent independently of any one drawing tool, compile that intent into multiple outputs, and bridge standards, domains, and render targets through explicit contracts.

This is why the opportunity looks more like LLVM than like another editor. A durable platform at this layer can sit beneath many workflows and above many incumbent tools. If EngineeringOS succeeds, its leverage comes from owning the missing coordination layer, not from outdrawing every existing product.

Strategic Conclusion

Industry analysis points to one conclusion: the defensible layer is semantic infrastructure. Commercial incumbents are too entrenched to replace head-on, and open-source projects are too valuable to ignore. The rational move is to build the layer they all lack, integrate with the tools they already provide, and define a standard that can outlast any single UI or file format.

Platform Shift

The deepest claim in EngineeringOS is that engineering software is entering a platform shift, not just a tooling upgrade. The change is larger than better CAD, faster editors, or more AI features. It is a shift in the architectural center of the whole stack.

The Three Eras

Paper Era
        ->
CAD Era
        ->
Semantic Engineering Era

The paper era organized engineering around manually produced documents. The CAD era digitized those documents and made representation faster, richer, and easier to revise. But even in the CAD era, the drawing or project file still remained the practical source of truth. Meaning stayed embedded indirectly inside pages, symbols, coordinates, naming conventions, and vendor-specific data models.

The semantic engineering era moves the source of truth upward. It treats engineering meaning itself as explicit, structured, and compilable.

From Drawing To Meaning

Another useful model is:

Drawing
        ->
Model
        ->
Meaning

Drawings are views for humans. Models are better containers than drawings, but many models are still too tied to one tool or one domain representation. Meaning is the deeper layer: identities, functions, constraints, relationships, behaviors, and standards-backed logic expressed explicitly enough to survive translation across tools and workflows.

Why The Drawing-Centric Model Breaks

Drawing-centric systems break down whenever engineering meaning has to move. Validation becomes tool-specific. Interoperability becomes guesswork. Change propagation becomes manual coordination across many outputs. Reuse becomes shallow because the real engineering logic is buried in documents rather than represented as governed semantic artifacts.

This is why the problem is not just user-interface age or file-format inconvenience. The current center of authority is too low in the stack.

Why AI Matters, But Is Not The Center

AI makes the shift more urgent because it exposes how brittle drawing-centric systems are. Models work well with language, graphs, rules, and structured semantic contexts. They work poorly when meaning must be inferred from pages, coordinates, brittle XML dialects, or application-specific files. The closer engineering truth moves toward semantics, the more useful AI becomes.

But AI is not the platform itself. EngineeringOS should be understood as the semantic infrastructure that makes trustworthy engineering AI possible. AI is the first major beneficiary of the platform shift, not the definition of the platform.

Why Existing Tools Become Renderers

The shift does not erase the installed base. Engineers still need schematics, models, reports, compliance views, procurement artifacts, and enterprise integrations. Existing CAD, CAE, electrical, PCB, and mechanical systems therefore remain important.

What changes is their role. Once the semantic layer exists, those systems no longer need to be the place where engineering meaning originates. They become output environments, compatibility surfaces, and renderers around a deeper source of truth.

The Strategic Consequence

If this shift is real, then the decisive question is not whether one new tool can beat every incumbent editor. The decisive question is whether a semantic source of truth can be introduced above them. When that becomes possible, the platform stops being a feature project and becomes a new infrastructure layer.

Design Principles

EngineeringOS should be governed by principles that remain stable even as implementations, products, and AI models change. These principles are not style preferences. They are the constitutional rules that keep the project from collapsing into another drawing editor, another vendor-shaped platform, or another shallow AI wrapper.

1. Semantics Before Drawings

Engineering meaning must exist explicitly before it is expressed as a drawing, report, layout, or export. If a feature only works by making the drawing authoritative again, it violates the architecture.

2. Open Standards Before Vendor Lock-In

Where relevant public standards already define a language, exchange boundary, or domain reference, EngineeringOS should align with them. Closed internal structures should not become the default merely because they are faster to invent.

3. AI Augments Engineering Judgment, Not Replaces It

AI should help generate, review, transform, and extract engineering meaning, but it must not become the unreviewable authority over it. Human accountability and governed artifacts remain essential.

4. Never Reinvent Solved Problems

Geometry kernels, parser frameworks, editor protocols, storage systems, symbol ecosystems, and compatibility libraries should be reused where they are already mature. Strategic effort should be reserved for the missing semantic layer.

5. Own The Semantic Layer

EngineeringOS must own the language, ontology, intermediate representation, compiler logic, rule contracts, and governed knowledge that define engineering meaning. If that layer is outsourced, the project loses its reason to exist.

6. Everything Is Pluggable

Domains, renderers, importers, exporters, standards packs, rule sets, AI workflows, and product surfaces should grow through explicit extension points. The center should remain small and durable while the edges remain open.

7. Every Engineering Decision Should Be Traceable

Rules, standards mappings, compiler outcomes, and semantic transformations should be explainable in governed terms. A system that cannot explain why it concluded something is not strong enough to carry engineering authority.

8. Human-Readable, Machine-Executable

Engineering knowledge should be readable by people and operable by machines. This is the discipline that keeps the platform legible enough for governance while making it formal enough for automation and compilation.

Why These Principles Matter

These principles are how EngineeringOS becomes durable. They keep the project aligned with a movement-sized goal rather than letting it shrink into another product silo. If the implementation evolves but these principles stay intact, the platform can grow without losing its identity.

Open Source Strategy

EngineeringOS should not try to win by replacing the whole engineering software world. It should win by providing the missing semantic layer that lets the rest of that world interoperate more intelligently. The strategy is not replacement. The strategy is leverage.

Leverage, Don't Replace

This is one of the defining choices of the project. EngineeringOS should stand on top of the strongest ecosystems that already exist instead of fighting them all at once.

Geometry: OCCT
PCB: KiCad
Electrical: QElectroTech
Mechanical: FreeCAD
Visualization: OpenUSD
Compiler method: LLVM philosophy

That decision signals technical maturity. It says the project understands where real leverage lives: not in rebuilding solved subsystems, but in owning the layer that coordinates them.

What EngineeringOS Must Own

EngineeringOS must own the language, ontology, intermediate representation, compiler pipeline, rule engine, plugin contracts, and governed knowledge layer that define how engineering meaning is expressed and transformed. These components are the architectural core. If they are left to external tools, the platform loses its strategic center.

Owning the semantic layer does not mean building a monolith. It means being able to say, with precision, what a device is, how relationships are represented, how rules execute, how standards are mapped, and how outputs are derived without surrendering those questions to downstream vendors or legacy file formats.

What EngineeringOS Must Reuse

EngineeringOS should deliberately reuse open-source assets that solve adjacent but already-mature problems. Geometry should come from established kernels such as OCCT. Electrical compatibility can draw from QElectroTech. PCB and mechanical interoperability can lean on KiCad and FreeCAD. Parsing, editor tooling, storage, analytics, and rendering foundations should be reused where they are already strong.

This is not compromise. It is strategic discipline. The project should not waste its best effort recreating systems whose value is already widely available.

Shared Engineering Knowledge As Infrastructure

The semantic layer matters not only because it improves software architecture, but because it changes what can be shared. Once rules, ontology packs, standards mappings, templates, validation logic, domain libraries, and workflow modules become governed semantic artifacts, they can be published, versioned, improved, and reused collectively instead of dying inside one company archive or one vendor toolchain.

In software, ecosystems such as npm and Maven Central turned accumulated knowledge into reusable infrastructure. Open foundations such as Apache and Linux made shared public layers possible at global scale. EngineeringOS should aim for the same structural effect in engineering: a semantic infrastructure layer where knowledge compounds over time and every serious contribution can strengthen the whole ecosystem.

Why Forking Is Usually The Wrong Move

Forking is usually the wrong move because it imports another project's maintenance burden, historical constraints, and architectural assumptions into the center of this one. The default posture should be integration, adaptation, and contribution around stable boundaries. Forking should be exceptional, narrow, and peripheral.

Strategic Boundary

EngineeringOS is not a geometry kernel, not a schematic editor clone, not a symbol-library replacement, and not a thin AI wrapper over legacy files. It is the semantic, compiler, and governance layer that sits above those systems and makes them interoperable under a common source of truth.

That boundary should remain strict. The long-term asset is the open semantic infrastructure. Everything else should either serve that layer directly or remain outside the core.

Ecosystem Analysis

EngineeringOS sits inside a dense ecosystem of software platforms, standards, protocols, and implementation frameworks. The project is viable only if that ecosystem is classified correctly. Some assets should be reused directly. Some should be integrated through adapters. Some should be studied as reference architecture. Others should be treated as standards boundaries rather than implementation dependencies.

Four Reuse Modes

EngineeringOS should classify every external dependency by method, not by popularity.

Own: language, ontology, IR, compiler, rules, standards mapping, and plugin contracts.
Use directly: technologies such as Kotlin, Compose Multiplatform, WASM, LSP, ANTLR, Tree-sitter, SQLite, and DuckDB where direct leverage is stronger than reinvention.
Integrate: platforms such as OCCT, FreeCAD, QElectroTech, KiCad, AutomationML, and OPC UA that provide external capability or compatibility surfaces.
Study: systems such as OpenSCAD, LLVM, MLIR, SysML v2, OpenUSD, LibrePCB, Blender, IFC, and Kubernetes that contribute architectural lessons even when their code is not the main dependency.

Platform Inventory

OCCT is the industrial geometry kernel. FreeCAD is the practical mechanical workbench and STEP-facing ecosystem reference around that geometry world. QElectroTech is the most relevant open electrical symbol and schematic reference. KiCad is the PCB compatibility and ecosystem anchor. OpenSCAD is a design-philosophy reference for programmable modeling. LibrePCB is worth studying for cleaner PCB architecture and UX patterns. AutomationML, OPC UA, SysML v2, IFC, and IEC CIM matter as semantic and exchange references. LLVM, MLIR, LSP, ANTLR, and Tree-sitter matter as compiler and language-tooling references. SQLite, DuckDB, Neo4j, Skia, WebGPU, OpenUSD, Blender, and OpenBOM fill out the storage, rendering, analytics, visualization, and future digital-twin perimeter.

The Method Layer

The key lesson from the draft corpus is that EngineeringOS is not just an AI project and not just a CAD project. It is a method for orchestrating many mature systems through one semantic core. That method is compiler-first at the center, plugin-first at the edges, standards-aware in governance, and selective in reuse. It does not absorb external code indiscriminately. It gives each dependency a narrow, explicit role.

That method should remain visible in every future design document. When the project evaluates a dependency, it should always answer four questions: what capability does this system provide, at which boundary do we consume it, what do we refuse to inherit from it, and what strategic layer must remain under EngineeringOS control.

Practical Implication

The ecosystem is not a background list. It is part of the architecture. Every serious chapter about compiler design, plugin boundaries, Studio, cloud distribution, standards mapping, or enterprise integration should be legible against this ecosystem map. If the map is missing, the project drifts either into reinvention or into dependency capture.

Knowledge Distribution Mechanism

The semantic layer also creates a distribution mechanism for engineering knowledge itself. Once rules, ontology packs, standards mappings, validation modules, templates, and domain-specific semantic assets are expressed as governed artifacts, they can be shared the way software ecosystems share packages. That makes EngineeringOS more than a modeling stack. It becomes a knowledge exchange system where engineering method can accumulate instead of restarting inside each isolated organization.

This is the practical mechanism behind the platform thesis. A plugin ecosystem is not only about renderers and integrations. It is also about reusable engineering intelligence. The more publishable the semantic artifacts become, the more the ecosystem behaves like a true package repository for engineering knowledge rather than a loose set of disconnected tools.

Business Strategy

EngineeringOS should be built as open infrastructure first and commercial surface second. If the semantic layer becomes widely trusted, the project can grow into more than a software product. It can become a movement around shared engineering knowledge and open engineering infrastructure.

Foundation Before Product Capture

The core semantic assets should live in an open governance layer: language, ontology, intermediate representation, compiler contracts, plugin interfaces, standards mappings, and the reference documentation that explains them. This is the part that benefits from trust, public review, ecosystem legitimacy, and long-term durability.

Commercial offerings should sit above that base, not consume it. Hosted collaboration, managed knowledge distribution, organizational policy, audit, support, private registries, and enterprise deployment are valid commercial layers precisely because they amplify the public core instead of replacing it.

Why This Model Fits The Architecture

The architecture only works if many tools, domains, and organizations can trust the semantic layer as neutral infrastructure. That trust is easier to build when the core is open and durable. It is the same structural logic that made open software infrastructure such as Linux, Git, Kubernetes, and LLVM more powerful than isolated products.

EngineeringOS should aim for the same role in engineering: not merely a product vendor, but a standardization anchor around which a larger ecosystem can form.

Revenue Logic

The most credible revenue lines are enterprise hosting, private knowledge packs, managed standards workflows, premium collaboration features, vertical solution packs, support, integration services, and eventually a marketplace around plugins, rules, libraries, and reusable engineering logic. Charging for the semantic core itself would weaken the chance of broad adoption. Charging for operational and organizational capability above it strengthens the business while keeping the architecture coherent.

Network Effects And Global Benefit

The deeper strategic consequence is that EngineeringOS can create compounding network effects around shared engineering knowledge. If the semantic layer becomes the place where rules, domain packs, standards mappings, and reusable engineering logic are published and maintained, each contribution can improve the usefulness of the whole ecosystem.

That is the same kind of public compounding effect open software infrastructure created when shared layers formed around Apache, Linux, and package ecosystems. The long-term asset is not only the software surface. It is the growing body of interoperable engineering knowledge that the platform makes publishable, reusable, and economically valuable across the entire industry.

Why This Can Become A Movement

Projects become movements when they name a fundamental shift clearly enough that other people want to build inside it. EngineeringOS has that potential because it is not merely proposing another tool. It is proposing a new center of gravity for engineering software.

If the project succeeds, people will not participate only because they like one UI or one compiler implementation. They will participate because they believe engineering knowledge should become open, semantic, traceable, and reusable at global scale.

Strategic Constraint

Business strategy must never force the project to compromise its semantic center. EngineeringOS cannot become a thin enterprise wrapper over legacy tools, and it cannot hollow out the public layer until the standard disappears. The business exists to accelerate the infrastructure, not to consume it.

Roadmap

The roadmap follows the manifesto architecture in sequence. EngineeringOS starts with the semantic core, then adds executable compilation, then AI-native workflows, then Studio as a projection layer, and only after that opens cloud and enterprise surfaces. This ordering is deliberate because the project's authority must be established in language, ontology, IR, governed knowledge compilation, and compiler logic before it is expressed in any richer interface or commercial surface.

Phase 1: Language, Ontology, IR

Phase 1 establishes the semantic core. The first responsibility of EngineeringOS is to define Engineering Language, Engineering Ontology, and Engineering IR clearly enough that engineering intent can exist as a governed source of truth independent of any downstream tool. This phase covers the language surface, ontology vocabulary, canonical IR model, parser boundary, and the public specifications that make those layers stable and reviewable.

Phase 1 is not a GUI phase. It is the period in which the architecture proves that meaning can be authored, normalized, and preserved before any rich visual shell is allowed to define system behavior. If this layer is weak, every later phase collapses back into drawing-centric software.

Phase 2: Compiler, Rules, Exporters

Phase 2 turns the semantic core into an executable system. The priority here is the Engineering Compiler: explicit passes for lowering, normalization, validation, rule execution, derivation, and target preparation. This phase also establishes the base Knowledge Compiler path as part of the architectural model so that governed ontology additions, mappings, and rules have a formal route into project compilation even before AI acceleration becomes a workflow focus. The point is not to add surface complexity, but to make the semantic core operational and testable.

This phase also introduces rule packs and exporters. Reports, structured exports, renderer inputs, and compatibility targets should all be compiled consequences of the same IR rather than separate sources of logic. Exporters belong after the compiler boundary because they depend on validated meaning, not on ad hoc file conversion.

Phase 3: AI-Native Workflows

Phase 3 introduces AI-native workflows only after the semantic and compiler contracts exist. At this stage, natural-language authoring, transformation assistance, review flows, and model-aware automation can operate over stable language and IR interfaces instead of over drawings or prompts alone.

This phase also introduces AI-native acceleration of standards knowledge extraction through the already-established Knowledge Compiler path. Standards documents, manufacturer references, and reviewed AI extractions are turned into governed ontology additions, mappings, and rules that can inform project compilation. AI is useful here because it can accelerate extraction and proposal, but the accepted knowledge remains reviewable infrastructure rather than opaque model behavior.

Phase 4: Studio

Phase 4 introduces Studio as a projection layer over the semantic core and compiler pipeline. By the time Studio appears, the architecture should already be able to author, validate, and export meaning without relying on a rich interface to hide system logic. Studio therefore exists to make the platform more usable, inspectable, and adoptable, not to become the deepest authority in the stack.

This distinction matters because Studio should consume and expose the same semantic and compiler contracts already established in earlier phases. It can provide authoring surfaces, visual projections, inspections, and workflow composition, but it should remain downstream of the core rather than redefining it.

Phase 5: Cloud And Enterprise

Phase 5 adds cloud and enterprise surfaces only after the core has stabilized. By this point, the semantic model, compiler boundary, rules, exporters, and Studio projection model should already be coherent enough that collaboration, governance, deployment, and organizational integrations can build on a durable substrate.

This phase includes hosted workflows, multi-user coordination, managed knowledge distribution, policy surfaces, and enterprise-facing integration layers. These belong last because they amplify the platform's core assumptions; they should not be used to discover what those assumptions are.

Adoption Milestones

The first adoption milestone is semantic credibility: users can see that language, ontology, and IR preserve engineering meaning more faithfully than file-centric workflows. The second is executable credibility: compiler passes, rules, and exporters produce repeatable outputs from one source of truth. The third is workflow credibility: AI-native authoring and standards knowledge extraction improve engineering practice without replacing governance.

The fourth milestone is interface credibility: Studio proves that a rich surface can remain subordinate to the semantic core rather than becoming another hidden application center. The fifth is organizational credibility: cloud and enterprise surfaces are adopted because the core is already stable enough to support collaboration, compliance, and integration at scale.

Compiler

The compiler is where EngineeringOS stops being a theory of semantics and becomes an executable engineering system. Its job is to take structured engineering meaning, apply rules and validations, derive consistent outputs, and generate the artifacts required by tools, workflows, and organizations downstream. In this sense, the compiler is not a secondary component but the operational heart of the platform, and this chapter defines the responsibilities and boundaries of that heart.

Compiler Purpose

The purpose of the Engineering Compiler is to convert semantic engineering intent into validated and reusable outputs. It does this by operating over Engineering IR with explicit passes that check correctness, derive implied structure, and prepare information for reports, integrations, and targets. The compiler is where the platform enforces that semantics are not merely described but made operational.

This purpose is broader than file generation. The compiler is responsible for preserving coherence across views, ensuring that derived artifacts agree with the same source model, and making rule execution visible and testable. Without a compiler, the platform would degrade into a collection of editors, scripts, and exporters with no dependable center.

Input And Output Model

The compiler consumes normalized Engineering IR together with the contracts that give that IR meaning: the Engineering Ontology, rule packs, extension metadata, and Standards Mapping artifacts. Engineering Language, imported files, and AI-generated candidates are not compiler outputs in their raw form; they are inputs that must first be lowered into the canonical representation the compiler understands.

The compiler produces more than one class of output. It emits diagnostics, validated and enriched IR, numbering and cross-reference derivations, reports, machine-readable exports, and target-ready structures that a Renderer or integration adapter can consume. In other words, the compiler turns one semantic source into many coordinated consequences.

Pass Structure

The Engineering Compiler should be structured as a sequence of explicit passes rather than hidden state transitions. Typical passes include normalization, identity resolution, ontology conformance checks, relationship validation, rule execution, derivation of references and numbering, report assembly, and target preparation. Each pass should be deterministic, inspectable, and scoped to a clear responsibility.

This pass model matters because engineering logic grows over time. When the compiler is organized into clear passes, new rule sets, domain extensions, and targets can be inserted without turning the entire system into one opaque procedure. A compiler-centered architecture is maintainable precisely because responsibilities are separated, ordered, and reviewable.

Validation And Rules

Validation is the first operational duty of the compiler. It confirms that the IR is structurally sound, semantically well-typed, and consistent with domain and standards expectations. Some validations are universal, such as identity consistency or relationship cardinality. Others come from domain packs and Standards Mapping, where the platform must check requirements derived from governed engineering knowledge.

Rules should therefore be treated as executable knowledge rather than UI-side conveniences. The compiler should distinguish errors, warnings, and advisory findings, and it should preserve enough provenance that a result can be traced back to ontology definitions, rule sources, or mapped standards. This traceability is what makes the compiler credible in engineering settings rather than merely convenient.

Reports And Render Targets

Reports and render targets are downstream products of compilation, not separate sources of truth. BOMs, wiring tables, cross-reference lists, compliance summaries, PDFs, SVGs, and external project exports should all be derived from the same compiled semantics. The compiler assembles the engineering content of those outputs, while the Renderer or target adapter handles presentation and format-specific emission.

This distinction keeps the architecture clean. A Renderer should not be responsible for recovering missing engineering meaning from incomplete data, and a report generator should not invent its own business logic in isolation. The compiler owns derivation and consistency; target-facing components own formatting and transport.

Engineering Compiler Versus Knowledge Compiler

EngineeringOS needs two different compiler-shaped systems with different authorities. The Engineering Compiler compiles engineering projects: it takes instance-level intent and produces validated instance-level outputs. The Knowledge Compiler compiles engineering knowledge: it turns standards documents, manufacturer references, and reviewed AI extractions into governed ontology updates, rules, and mappings that the operational compiler can later use.

Keeping these responsibilities separate is essential. The operational compiler must be deterministic and project-focused, while the knowledge side is iterative, evidence-driven, and mediated by a Human Review Loop. If the two are collapsed, project compilation becomes unstable and standards interpretation becomes opaque. If they remain distinct, EngineeringOS can evolve its knowledge base without compromising the reliability of engineering execution.

Ontology

Ontology is the conceptual center of EngineeringOS because it defines what the system believes engineering objects, relationships, constraints, and behaviors actually are. Without an explicit ontology, language becomes shallow, AI becomes unreliable, and compiler logic becomes a collection of ad hoc rules tied to specific tools or domains. EngineeringOS therefore treats ontology not as documentation garnish, but as foundational infrastructure that connects standards, human understanding, and executable engineering logic.

Why Ontology Is Central

The Engineering Ontology gives the rest of the platform a shared vocabulary for meaning. Engineering Language depends on it to express intent precisely, Engineering IR depends on it to encode meaning canonically, and the Engineering Compiler depends on it to validate relationships and apply rules without collapsing back into tool-specific assumptions. Without this layer, every feature would smuggle its own private model of reality into the system.

Ontology is central for a second reason: it separates engineering semantics from any one domain application's UI or file format. A breaker, signal, function, enclosure, safety constraint, or control relationship should be defined by its meaning inside the architecture, not by how one tool happens to draw or serialize it. The ontology is therefore the place where conceptual authority is made explicit and reviewable.

Core Concepts

The core ontology should begin with concepts general enough to survive many engineering domains. Entities, devices, ports, connections, signals, functions, constraints, behaviors, and relationships form the minimum vocabulary from which richer domain models can grow. These concepts are not merely class names. They define what kinds of things can exist, how they can be identified, and what kinds of statements the system is allowed to make about them.

This base layer matters because premature specialization makes the architecture brittle. Electrical engineering may dominate early use cases, but the conceptual substrate has to support future mechanical, hydraulic, robotics, and industrial-system extensions without starting over. The core ontology therefore favors durable abstractions first and domain specificity second.

Relationships, Constraints, And Behavior

Engineering meaning is not captured by object lists alone. The Engineering Ontology has to define how objects relate, what constraints govern them, and what behaviors they participate in. A motor controlled by a contactor, a cable terminating at two points, or an emergency stop isolated from normal control logic are not formatting choices. They are semantic statements that must be represented explicitly.

Constraints and behavior are especially important because they are where engineering logic becomes executable. Relationships define topology and dependence, constraints define what must or must not be true, and behavior defines how state, control, or function changes over time or circumstance. When these elements are missing, rule systems become a patchwork of exceptions. When they are explicit, the compiler can reason over engineering structure instead of reverse-engineering it from drawings.

Domain Extensions

Domain growth should happen by extension, not by rewriting the center. A domain Plugin can add electrical, mechanical, hydraulic, robotics, or other specialized concepts, but it should do so by inheriting from or aligning with the shared conceptual base. Electrical concepts such as relay, terminal, cable, breaker, or PLC become domain refinements of core engineering concepts rather than an isolated ontology with no bridge back to the platform.

This extension model keeps the Engineering Ontology both stable and open. The core remains small enough to govern carefully, while specialized communities can evolve domain packs at the edges. That is the only sustainable way to support a broad engineering ecosystem without hard-coding one discipline's vocabulary as the permanent definition of engineering itself.

Standards Mapping

Standards Mapping is the process by which public engineering standards, manufacturer references, and reviewed domain knowledge are connected to ontology concepts, relationships, and constraints. The purpose is not to copy standards documents clause-for-clause into the model. The purpose is to translate standards-backed meaning into reusable semantic structures that the platform can validate and compile.

This mapping layer is what turns the ontology into a bridge between public knowledge and executable logic. The Knowledge Compiler prepares these mappings as governed knowledge artifacts that the Engineering Compiler consumes during project compilation. A standard may imply required relationships, cardinality limits, naming expectations, safety separations, or device obligations. Once those implications are mapped into the Engineering Ontology, they can inform Engineering IR, rule packs, and compiler behavior in a form that is inspectable and testable.

Governance And Review

Ontology changes should be governed as infrastructure, not improvised as feature work. Proposed concepts, relationship types, constraints, and mappings need provenance, review, and versioning. AI can assist with extraction and suggestion, but acceptance belongs to a Human Review Loop involving domain experts and maintainers who are accountable for conceptual quality and standards fidelity.

This governance model protects the platform from semantic drift. The ontology will accumulate value only if users can trust that concepts are reviewed, compatible, and intentionally evolved. In EngineeringOS, the Engineering Ontology is not a side document. It is a governed contract between standards, experts, language, IR, and compiler execution.

Engineering IR

EngineeringOS requires a canonical intermediate representation because neither natural language nor author-facing DSL is sufficient as the stable computational core of the system. The IR is the layer where engineering meaning becomes explicit, structured, and durable enough to survive transformation, validation, versioning, and rendering across many targets. This chapter explains why the IR exists, how it relates to the ontology and language layers, and why it must remain distinct from any single file format or UI model.

Why IR Exists

Engineering IR exists to provide a stable execution boundary between human-facing inputs and machine-facing outputs. Natural language is too ambiguous, and Engineering Language is too author-oriented, to serve directly as the system's long-term computational contract. The IR is where engineering intent becomes explicit enough for validation, derivation, diffing, merging, and compilation.

This layer is also what allows EngineeringOS to support multiple authoring surfaces without multiplying compiler logic. Different editors, importers, or AI-assisted flows can all lower into the same IR if they preserve the same semantics. The result is one canonical model beneath many input experiences.

IR Versus DSL

Engineering Language is for writing and reading intent. Engineering IR is for preserving and transforming intent canonically. The distinction is structural, not cosmetic. A DSL can optimize for readability, authoring ergonomics, or domain idioms, while the IR must optimize for explicitness, completeness, and compiler stability.

The IR must therefore remain distinct from any one DSL syntax. Multiple surface languages may eventually target the same representation, and the same project may move between natural language generation, structured language authoring, and imported data. If the IR collapses into a single DSL or parser shape, the architecture loses the independence it needs to remain durable.

Canonical Representation

The canonical representation should encode the things the platform actually needs to reason about: identities, typed entities, relationships, constraints, behavior references, provenance, and extension points aligned with the Engineering Ontology. It should preserve meaning that downstream passes and targets depend on, not merely store whichever syntax happened to be used at authoring time.

That is why Engineering IR is closer to a semantic graph or typed model than to a document transcript. It is the place where relationships are first-class, where constraints are explicit, and where hidden assumptions are surfaced into structured form. A canonical IR is not valuable because it looks elegant. It is valuable because it makes semantic equivalence and compiler behavior testable.

IR Is Not Layout Or Geometry

One of the most important architectural boundaries in EngineeringOS is that Engineering IR must not collapse into either layout intent or geometry. Most existing engineering tools mix engineering meaning, presentation decisions, and rendering artifacts into one project structure. That makes synchronization brittle, automation shallow, and semantic reasoning dependent on coordinates and drawing conventions.

EngineeringOS should separate these concerns explicitly.

Engineering Intent
        ->
Semantic Model
        ->
Presentation / Layout Model
        ->
Geometry Model

These layers serve different purposes. Engineering IR describes what the system is: devices, functions, constraints, signals, relationships, and identities. A layout model describes how humans want to see that system: grouping, relative placement, flow, cabinet organization, alignment, and view-specific arrangement. A geometry model describes the final rendered form: coordinates, paths, symbols, splines, polygons, and exact graphical placement.

That separation is not cosmetic. It is what allows one semantic model to support multiple synchronized views, multiple downstream targets, and stable regeneration without making the drawing the source of truth again.

Identity And Stability

Stable identity is one of the main reasons the IR must exist at all. Devices, functions, connections, and other engineering objects need identifiers that survive page moves, renumbering, layout changes, and target regeneration. If identity is tied to coordinates, drawing order, or exporter-specific handles, then diffing and synchronization become fragile immediately.

Engineering IR should therefore preserve stable object identity and explicit references between objects. That stability enables semantic diff and merge, repeatable compiler passes, and reliable regeneration across many targets. It also makes change history more meaningful because the system can track what changed in engineering terms rather than only what changed in a text file.

This is also why layout changes must not redefine engineering identity. Moving a motor to another page, regrouping devices in a cabinet view, or choosing a different presentation scheme should not produce a new engineering object. The semantic model remains stable while views and renderers change around it.

Serialization And Compatibility

The IR may be serialized in several ways over time, but no serialization should be mistaken for the IR itself. JSON, binary formats, database layouts, and transport schemas are compatibility surfaces, not the conceptual definition of the representation. EngineeringOS should be able to evolve storage and exchange mechanisms without redefining the semantic model each time.

Compatibility should therefore be managed at the level of schema evolution, versioned adapters, and explicit upgrade paths. When the platform needs to change Engineering IR, it should do so as a governed architectural decision tied to ontology and compiler contracts, not as an accidental consequence of a new UI or exporter.

This boundary is especially important when the platform interacts with established standards such as AutomationML. EngineeringOS should learn from those standards and interoperate with them, but it should not allow their serialization formats or runtime assumptions to become the internal definition of the IR. A format such as AutomationML may appear on both sides of the compiler as an importer and an exporter, but it should never replace the semantic center of the platform.

Natural Language
DSL
AutomationML
        ->
Engineering IR
        ->
AutomationML
EPLAN
KiCad
QElectroTech
SVG

That is the correct ownership boundary. External standards are adapters and compatibility surfaces. Engineering IR remains the native semantic contract.

Role In The Compiler Pipeline

Engineering IR is the working substrate of the Engineering Compiler. Parsers, importers, and AI-assisted authoring flows lower into it; validation, derivation, and reporting passes operate over it; and each Renderer or export target consumes a form derived from it. The compiler should be able to inspect, normalize, and transform the IR without needing to reinterpret author-facing syntax at every stage.

The IR also creates a clean boundary with the Knowledge Compiler. The knowledge side of the platform may produce ontology updates, rule packs, or Standards Mapping artifacts, but those outputs should influence project compilation through explicit contracts rather than by bypassing the IR. In this architecture, Engineering IR remains the canonical representation of engineering instances, while knowledge artifacts govern how those instances are interpreted.

In practical terms, that means the pipeline should evolve toward multiple explicit intermediate forms rather than one overloaded representation:

Engineering Language
        ->
Engineering IR
        ->
Layout IR
        ->
Geometry IR
        ->
Renderer / Target

This model allows each stage to own one responsibility. Engineering IR captures semantic truth. Layout IR captures view intent. Geometry IR captures exact renderable structure. Targets such as SVG, QElectroTech, EPLAN, or other downstream systems should consume derived forms rather than becoming the place where semantics, layout, and geometry are permanently entangled.

For the same reason, Engineering DSL should describe engineering meaning, not page coordinates or ad hoc drawing mechanics. Layout concerns may eventually have their own author-facing language or declarative configuration surface, but that should remain downstream of semantic engineering intent rather than mixed into it.

Graph

EngineeringOS needs a graph-oriented internal model because engineering meaning is defined as much by relationships as by objects. Devices, ports, functions, constraints, signals, and standards references form networks of dependency, not isolated records. The graph layer is therefore the operational shape of the IR, not an optional storage trick.

Why Graph Matters

A graph model gives EngineeringOS first-class representation for connectivity, control relationships, topology, provenance, and derived dependencies. It makes it practical to ask compiler questions such as which devices are connected, which constraints apply along a path, what systems are affected by a change, and which outputs must be regenerated after a semantic edit.

This is one of the draft's most important method points: AI should edit the semantic graph, not draw symbols. Compiler passes should validate and transform the graph, not reverse-engineer it from pages.

Identity And Edges

Every engineering node in the graph should carry stable identity. Every edge should carry explicit meaning, such as connects, controls, contains, references, or violates. That structure lets the compiler distinguish topology from containment, behavior from ownership, and semantic linkage from presentation linkage.

Stable identity plus typed edges is what makes diff, merge, traceability, and regeneration workable. Without that, the graph would collapse into another transient export structure instead of the computational center of the platform.

Storage And Execution Boundary

The graph does not require one storage engine forever. Early versions can use typed in-memory models with SQLite-backed persistence and selective analytics in DuckDB. If later scale demands graph-native storage, a system such as Neo4j can be evaluated as an implementation option. The architectural contract, however, is the graph semantics, not the database brand.

Plugin

Plugin architecture is how EngineeringOS grows without hard-coding every domain, target, and workflow into the core. The center of the platform should remain small enough to govern carefully, while specialized capability arrives through explicit extension points that attach to language, ontology, compiler, knowledge, and rendering boundaries.

Extension Classes

The draft establishes multiple plugin classes: renderer, importer, exporter, rule, standard, AI, language, and knowledge plugins. That taxonomy matters because each class extends a different architectural boundary. A renderer turns compiled semantics into a target representation. A rule plugin contributes executable engineering logic. A standards plugin contributes governed mappings. An AI plugin contributes bounded model-powered workflows without changing semantic authority.

Why Plugin-First Matters

A plugin-first design keeps EngineeringOS from becoming a monolith disguised as a platform. Electrical, mechanical, hydraulic, robotics, simulation, enterprise, and future domain layers can evolve at different speeds. If they all land in the core, the center becomes brittle. If they attach through stable interfaces, the core can remain durable while the ecosystem expands.

Governance Boundary

Plugins do not weaken governance; they make governance explicit. The platform should define what a plugin may extend, what contracts it must honor, how compatibility is declared, and how provenance is recorded when a plugin contributes rules, mappings, or outputs. This is especially important for standards, AI, and enterprise plugins, where ungoverned extension would quickly damage trust in the semantic layer.

AI

AI in EngineeringOS is valuable because it can operate on structured intent, standards knowledge, and semantic models rather than on drawings alone. Its role is to help generate, transform, review, and maintain engineering meaning, while the authority for accepted ontology, rules, and outputs remains grounded in standards, expert review, and compiler logic. This chapter defines the productive boundary of AI inside the platform.

AI Roles

AI is most useful where engineering meaning is present but costly to author or maintain manually. It can translate natural language into candidate Engineering Language, propose transformations over Engineering IR, summarize model changes, suggest refactorings, assist with migration across standards or target ecosystems, and help detect likely omissions before compilation. In each case, AI is operating on the Semantic Core, not on pixels or page geometry.

AI also has a legitimate role on the knowledge side of the platform. It can extract candidate entities, relationships, constraints, and evidence from standards documents and manufacturer material at a scale that would otherwise be too slow to sustain. This makes AI an important accelerator for ontology growth and rule discovery, provided that the results remain reviewable and governed.

AI Non-Roles

AI is not the authority over engineering semantics. It does not define the Engineering Ontology, it does not replace the Engineering Compiler, and it does not approve rules, outputs, or standards interpretations on its own. AI should not be allowed to silently mutate accepted knowledge or emit production artifacts whose governing logic cannot be traced and reviewed.

AI is also not the architectural center of EngineeringOS. The platform is built around Engineering Language, Engineering Ontology, Engineering IR, compiler logic, and governed knowledge. Models may change rapidly, but the system boundary should remain stable even as providers, prompting strategies, and model capabilities evolve.

Standards Extraction Pipeline

The standards extraction path should be explicit. Standards documents and related references are parsed into reviewable text and structure, segmented for evidence-preserving extraction, and then processed by models that propose candidate concepts, relationships, constraints, and Standards Mapping artifacts. Those candidates are not merged directly into the platform. They enter a governed review path.

From there, the reviewed outputs flow into the Knowledge Compiler, which packages them as ontology additions, rule proposals, and mapping updates that the rest of the platform can consume. This architecture gives AI a high-leverage role in knowledge acquisition without allowing model output to masquerade as accepted engineering truth.

Human Review Loop

The Human Review Loop is the control point that keeps AI useful without making it sovereign. Domain experts and maintainers review candidate ontology concepts, rule definitions, mappings, and extracted evidence before those artifacts are accepted into governed knowledge. Review must include provenance, change history, and enough context to understand what a model inferred and why.

This loop is not a temporary safety measure that disappears when models improve. It is part of the architecture because engineering standards, domain practice, and organizational accountability require explicit acceptance criteria. AI can reduce the cost of producing proposals, but it cannot remove the need for responsible approval.

Model Abstraction

EngineeringOS should treat model providers as interchangeable infrastructure behind stable platform contracts. Prompts, tool use, and structured outputs should be mediated through an abstraction layer or Plugin boundary so that the system does not hard-code one vendor, one model family, or one prompting style into its core architecture. What matters is whether a model can operate on the platform's structures and return reviewable results.

This abstraction should align AI interactions with the platform's canonical vocabulary. Models should consume and produce structures tied to Engineering Language, Engineering Ontology, and Engineering IR wherever possible. That keeps AI attached to durable interfaces instead of letting ephemeral provider behavior redefine the system over time.

Long-Term AI Boundary

Over the long term, AI may become the most common interface for authoring and maintaining engineering models, but it should remain inside a bounded role. It should help users reach the Semantic Core faster, help maintain governed knowledge more efficiently, and help explain or transform compiled engineering meaning. It should not become the hidden source of truth behind opaque outputs.

The durable architecture is therefore straightforward: the platform's authority lives in governed ontology, canonical IR, explicit compiler logic, and reviewed knowledge, while AI remains a powerful assistant operating through stable interfaces. That boundary allows EngineeringOS to benefit from rapid model progress without surrendering semantic integrity to model volatility.

Studio

Studio is the human-facing shell of EngineeringOS, not the source of truth. Its job is to expose the semantic core, compiler behavior, graph state, diagnostics, and downstream projections in a usable form without relocating authority back into UI state. That constraint is what separates Studio from a conventional CAD application.

Product Role

Studio should provide authored language views, semantic inspectors, graph-oriented navigation, diagnostics, report previews, and target projections such as schematic, panel, BOM, or 3D-adjacent views. It should make the compiler pipeline visible and operable. It should not hide core logic behind one privileged editor surface.

Technology Direction

The draft is clear about the preferred direction: Kotlin Multiplatform for the shared implementation base, Compose Multiplatform for the UI shell, and WASM for browser delivery and embeddable views. That stack is attractive because it keeps the language and product surfaces aligned while supporting desktop and web deployment from one architecture.

The deeper technology rule is that Studio should remain renderer-agnostic even if one stack is preferred at a given moment. The detailed framework comparison and UI abstraction strategy live in docs/technologies/15-ui.md.

Boundary

Studio should remain downstream of language, ontology, IR, graph, and compiler contracts. If a workflow only works in Studio and cannot be explained at the semantic or compiler boundary, that is a design failure. Studio exists to make the platform adoptable, not to become a second hidden architecture.

Cloud

Cloud is a later-stage distribution and coordination layer for EngineeringOS. It should provide collaboration, managed knowledge distribution, policy, audit, tenancy, and organizational integration only after the semantic core and compiler contracts are stable enough to support those capabilities without constant architectural churn.

Why Cloud Comes Later

The draft repeatedly warns against discovering the core through enterprise features. Cloud surfaces amplify the platform; they should not define it. Multi-user workflows, hosted compilers, shared knowledge packs, and policy-controlled distribution only become credible once the underlying semantic model, plugin system, and compiler behavior are already governed and testable.

Cloud Responsibilities

The cloud layer should eventually handle collaborative workspaces, managed standards and knowledge updates, centralized rule distribution, audit trails, organization policy, deployment control, and integrations into enterprise systems. In other words, cloud is where semantic infrastructure becomes operational infrastructure for teams.

Enterprise Boundary

Cloud should not own domain meaning. It distributes and governs artifacts produced by the open semantic core. That distinction keeps enterprise requirements from swallowing the platform and ensures that hosted capability remains an acceleration layer above a stable public architecture.

Layout And Geometry

EngineeringOS should distinguish clearly between engineering meaning, layout intent, and geometry. This is not a secondary implementation detail. It is one of the foundational architectural separations of the platform.

Most engineering tools collapse these layers into one file and one editing surface. As a result, engineering semantics, presentation choices, and rendering artifacts become tightly coupled. That coupling makes it difficult to support multiple synchronized views, reliable automation, renderer independence, and trustworthy AI. EngineeringOS should reject that structure explicitly.

The Three-Layer Model

Engineering Intent
        ->
Semantic Model
        ->
Presentation / Layout Model
        ->
Geometry Model

These layers answer different questions:

Engineering IR: What the system is.
Layout IR: How humans want to see it.
Geometry IR: How that view is rendered precisely.

Treating them as one model makes every layer weaker. Separating them makes the system more durable.

Engineering Meaning

The engineering layer is responsible for semantic truth: devices, functions, signals, constraints, relationships, identities, and governed references to standards or rules. This is the layer that should survive independent of any page, coordinate system, or rendering target.

An engineering authoring language should therefore describe engineering intent rather than drawing mechanics. It may express that a breaker protects a motor, that a relay controls a circuit, or that a safety function constrains operation. It should not need to encode x/y position, pixel distance, or arbitrary presentational alignment in order to remain valid.

Layout Intent

The layout layer is responsible for view logic. It describes how humans want to arrange and inspect the semantic model in a particular context: cabinet views, wiring views, functional views, power views, safety views, and other presentation structures.

This layer may encode grouping, relative placement, alignment, flow direction, routing preferences, cabinet composition, and view-specific emphasis. Those choices matter operationally, but they do not redefine engineering meaning. Layout is a projection of semantic truth, not the source of it.

This distinction is especially important because the same engineering model may legitimately support many layouts at once. Different teams, tasks, or lifecycle phases may require different views over the same semantic project without creating separate engineering realities.

Geometry

The geometry layer is responsible for exact renderable output. Coordinates, paths, line segments, splines, polygons, symbol placement, text boxes, and final drawing primitives belong here. Geometry is the realized output of layout and rendering decisions.

In this architecture, geometry should remain downstream of both semantic meaning and layout intent. It is necessary, but it is not authoritative. If geometry becomes the deepest source of truth again, the platform collapses back into the same structural weakness found in conventional CAD-centric systems.

Compiler Consequence

This architectural separation suggests a compiler pipeline with multiple explicit intermediate forms:

Engineering Language
        ->
Engineering IR
        ->
Layout IR
        ->
Geometry IR
        ->
SVG / QET / EPLAN / FreeCAD / Other Targets

Each intermediate representation should own one concern:

Engineering IR preserves semantic truth.
Layout IR preserves presentation intent.
Geometry IR preserves exact renderable structure.

That separation gives the platform a cleaner contract at every stage and prevents one representation from becoming overloaded with responsibilities it cannot carry well.

Why This Matters

Once meaning, layout, and geometry are separated, the same engineering project can support multiple synchronized views without duplicating the underlying design. Cabinet layout, wiring layout, functional layout, power layout, and safety layout can all derive from the same engineering model while remaining free to express different presentational logic.

This also makes AI more useful. AI should operate on semantic and layout intent rather than on brittle pixel-level manipulations. The right instruction is not "move this object twenty pixels." It is "group all safety devices together" or "place the motor to the right of its protective breaker." That kind of operation becomes more reliable only when the platform has explicit layers for meaning and layout.

Architectural Principle

EngineeringOS should treat this separation as a governing principle:

semantics define what the system is
layout defines how humans choose to view it
geometry defines how that view is rendered

AutomationML is one of the most important industrial reference models available to EngineeringOS. It matters not because EngineeringOS should become AutomationML internally, but because AutomationML demonstrates that industry has already converged on a serious way to describe engineering objects, interfaces, relationships, and exchange boundaries.

The correct lesson is therefore not "adopt AutomationML as the platform." The correct lesson is: learn from AutomationML, interoperate with AutomationML, and keep the semantic center of EngineeringOS independent from it.

Why AutomationML Matters

AutomationML exists because industrial engineering needs a structured way to exchange engineering information across tools, vendors, and lifecycle stages. It is strong precisely where conventional CAD-style files are weak: object identity, interface structure, reusable templates, explicit relationships, and standards-facing interoperability.

That makes it one of the most valuable external references for EngineeringOS. It has already answered an important question that many systems still handle poorly: what counts as an engineering object, and how should engineering objects be related?

What EngineeringOS Should Borrow

EngineeringOS should borrow the mature conceptual lessons of AutomationML.

Engineering object concepts such as components, roles, interfaces, relationships, attributes, hierarchies, and references.
Interface and connection thinking, which is one of AutomationML's strongest abstractions.
Reusable template ideas, which support repeatable engineering patterns instead of one-off object descriptions.
Property structures, especially where they help standardize engineering metadata.
Exchange discipline, meaning explicit contracts at system boundaries rather than ad hoc file translation.

These are proven semantic ideas. There is no value in inventing a weaker vocabulary merely to appear original.

What EngineeringOS Should Not Borrow

EngineeringOS should not borrow the implementation shape of AutomationML as its internal architecture.

Not an XML-first platform architecture.
Not CAEX as the native runtime model.
Not deep tree structure as the only organizing principle.
Not file-oriented workflows as the center of the user experience.
Not vendor-specific extension behavior as the basis of semantic growth.

AutomationML was designed for interoperability. EngineeringOS is being designed as a semantic language, compiler, and knowledge platform. Those are different responsibilities and they require different internal structures.

Mapping The Concepts Forward

AutomationML is strongest when treated as a source of semantic guidance rather than as a template for internal implementation.

AutomationML concepts
        ->
Object
        ->
Role
        ->
Interface
        ->
Relationship
        ->
Attribute

EngineeringOS should preserve the value of those ideas while extending them into a broader semantic system:

EngineeringOS semantic model
        ->
Entity
        ->
Type
        ->
Role
        ->
Interfaces
        ->
Properties
        ->
Behaviors
        ->
Constraints

This is an important boundary. AutomationML helps define object semantics well, but EngineeringOS must go further. Behavior, constraints, compiler semantics, traceable rules, and AI-operable engineering meaning are not fully solved by AutomationML and should remain native concerns of the platform.

Information Model Lessons

The CAEX information model remains highly instructive. Concepts such as InstanceHierarchy, InternalElement, Attribute, ExternalInterface, and InternalLink show a disciplined way to represent industrial structures. EngineeringOS should learn from that clarity.

But the internal representation of EngineeringOS should still remain its own.

AutomationML / CAEX
        ->
Project
        ->
InstanceHierarchy
        ->
InternalElement
        ->
Attribute
        ->
ExternalInterface
        ->
InternalLink

EngineeringOS
        ->
Workspace
        ->
Project
        ->
Entity
        ->
Property
        ->
Port
        ->
Connection

The semantic resemblance is useful. The internal ownership boundary is essential.

Serialization Is Not The Platform

The biggest mistake would be to confuse AutomationML's XML serialization with the architecture EngineeringOS should adopt internally.

EngineeringOS should not look like this at its core:

<InternalElement Name="Motor1">

Its authoring and semantic layers should instead remain native to the platform:

motor("M1") {
    power = 3.kW
    role = Drive
}

AutomationML belongs at the adapter boundary:

Engineering IR
        ->
AutomationML exporter

That distinction preserves readability, compiler integrity, and long-term architectural freedom.

AutomationML As Input And Output

AutomationML is valuable because it can appear on both sides of the compiler boundary without becoming the center of the platform.

Natural Language
DSL
AutomationML
Future Languages
        ->
Engineering IR
        ->
AutomationML
EPLAN
KiCad
QElectroTech
OpenSCAD
FreeCAD

AutomationML can therefore be both an importer and an exporter. It can help EngineeringOS enter industrial ecosystems and exchange with existing toolchains. But it should never become the semantic source of truth. That role belongs to Engineering Language, Engineering Ontology, Engineering IR, and the compiler pipeline that governs them.

Where EngineeringOS Must Extend Beyond AutomationML

AutomationML does not answer the full set of questions EngineeringOS must solve.

It does not define an AI-native engineering authoring model.
It does not define a compiler-centered semantic pipeline.
It does not define a broad ontology for reasoning across domains.
It does not define behavior and constraints with the depth EngineeringOS requires.
It does not define how AI systems should operate over engineering meaning safely and traceably.

Those are not failures of AutomationML. They are simply outside its primary mission. EngineeringOS should respect that boundary and solve its own problems directly.

Strategic Conclusion

AutomationML should be treated as a teacher, a reference model, and an interoperability adapter. It should not be treated as the internal identity of the platform.

EngineeringOS must own its semantic layer:

language
ontology
compiler
intermediate representations
knowledge and rules
AI-operable engineering semantics

UI strategy in EngineeringOS should be treated as a long-term architectural decision, not just as a toolkit choice. The platform should move away from coupling itself to legacy widget-era assumptions, but it should also avoid making any single modern UI framework the permanent center of the system. The right long-term direction is to replace framework dependence with a stable semantic UI boundary.

Core Principle

The UI should be replaceable. EngineeringOS should not bind its semantic and compiler architecture to Qt, Compose, Slint, GPUI, React, or any other single presentation stack. The compiler should produce stable semantic structures, and UI frameworks should consume those structures through an adapter layer.

Engineering Language
        ->
Engineering IR
        ->
Compiler
        ->
UI Adapter
        ->
Slint / GPUI / Compose / Web

This follows the same architectural rule used elsewhere in EngineeringOS: own the abstraction, not the renderer.

This UI boundary should be understood as downstream of a deeper architectural separation described in Layout And Geometry. EngineeringOS should distinguish between Engineering IR, Layout IR, and Geometry IR. UI frameworks consume those contracts; they do not define them.

Why Qt Is Not The Long-Term Center

Qt remains a strong desktop framework, especially for traditional engineering applications. It has deep cross-platform support, a large ecosystem, and long industrial history. But it was shaped around desktop widgets, mouse-driven interaction, imperative UI logic, and product assumptions from an earlier software era.

That makes Qt a poor long-term center for EngineeringOS. The platform is aiming for semantic editing, AI-assisted workflows, collaborative evolution, browser delivery, and renderer replaceability. In that context, Qt can remain a compatibility reference or transitional UI option, but it should not define the architecture of a new platform.

Comparative View

Criteria	Qt	Slint	GPUI	Compose Multiplatform
Open Source	Yes	Yes	Yes	Yes
Modern Architecture	Weak	Strong	Strong	Strong
AI-Friendly	Weak	Strong	Strong	Strong
Cross Platform	Very strong	Strong	Moderate	Very strong
Maturity	Very high	Medium	Early	High
WASM	Weak	Good	No	Excellent
Mobile	Good	Limited	No	Excellent
Ecosystem	Large	Small	Very small	Large
Community Growth	Slow	Growing	Growing	Strong

The point of this comparison is not to declare one universal winner. It is to show that the UI framework should remain an implementation choice below a stable semantic boundary.

Framework Assessment

Slint is attractive because it is lightweight, declarative, modern, and Rust-centered. It looks much cleaner than Qt for future-oriented engineering software, especially where rendering discipline and modularity matter. Its weakness is ecosystem scale and relative youth.

GPUI is interesting because it is GPU-first, async-oriented, and modern in its rendering philosophy. But it is still early, lacks industrial ecosystem depth, and does not yet offer a convincing browser or mobile story. It is promising, but not a safe sole bet for the platform.

Compose Multiplatform remains the strongest default choice for EngineeringOS today. It aligns with the broader Kotlin direction of the platform, supports desktop and browser delivery through WASM, and gives a practical route to mobile if that becomes relevant. Most importantly, it fits the current stack without forcing the project to split its product surface too early.

Recommended Direction

The recommended approach is not to choose one UI forever. It is to define a UI abstraction and let multiple renderers exist behind it.

Compiler
      ->
ViewModel
      ->
UI API
      ->
Compose
Slint
GPUI
React
Web

The compiler should never need to know which UI exists. That separation makes it possible to evolve the presentation layer without destabilizing the semantic core.

Semantic View Model

EngineeringOS should eventually define its own Semantic View Model, just as it defines Engineering IR for engineering meaning. Instead of letting a UI framework talk directly to compiler internals, the platform should expose a stable view-oriented semantic contract.

Engineering IR
        ->
Semantic View Model
        ->
UI Renderer
        ->
Compose / Slint / GPUI / React

This would make UI framework replacement an implementation detail rather than a platform crisis. It would also keep Studio aligned with the central rule of EngineeringOS: the stable asset is the model and its contracts, not the renderer.

Where Rust Fits

Rust is useful in the UI story, but not as the default language for the whole application. Its strongest role is in rendering, geometry-adjacent performance work, GPU paths, and high-performance algorithms. Kotlin remains the better home for compiler logic, DSLs, ontology, AI orchestration, plugin contracts, and business logic.

Rust
-----
Renderer
Geometry
GPU
High-performance algorithms

Kotlin
------
Compiler
DSL
Ontology
AI
Plugin system
Business logic

Proto/gRPC
----------
Communication

This split lets each language serve its strengths without forcing one implementation stack to absorb every concern.

Recommended Stack Today

If EngineeringOS were started today, the most pragmatic default would be:

Core platform: Kotlin Multiplatform
Compiler: Kotlin
DSL: Kotlin
Ontology: Kotlin
AI orchestration: Kotlin
Geometry: OCCT
Rendering engine: Rust where performance justifies it
Primary UI: Compose Multiplatform
Web delivery: Compose WASM
Experimental secondary UI path: Slint

That combination keeps the platform modular while avoiding dependence on a single UI technology. It also keeps the central architectural promise intact: the semantic layer remains the durable contract, and the UI remains replaceable.

Kernel v0

Kernel v0 is the minimal executable proof of the manifesto. Its purpose is not to launch a broad product surface, but to demonstrate that EngineeringOS can carry one project through a disciplined semantic pipeline and produce a compiled output from that pipeline.

Objective

The objective of Kernel v0 is to prove the architecture through the smallest useful slice of execution. That slice must begin with authored engineering intent, lower that intent into canonical structure, apply explicit rule logic, and produce a concrete export. The kernel is successful if it demonstrates the compiler-first path clearly enough that the manifesto becomes operational rather than rhetorical.

DSL -> IR -> Rule -> Export

This objective prioritizes the semantic core and execution boundary over any GUI surface. Kernel v0 exists to show that language, ontology-aligned structure, and compiler logic can already do real work before broader product layers are introduced.

Scope

The scope is intentionally narrow. Kernel v0 includes a minimal authoring DSL, a canonical IR model, one canonical rule evaluation step, and one canonical export path. The implementation should be small enough to inspect end to end, but complete enough to prove that the architecture can carry engineering meaning through compilation.

The authoring example remains intentionally simple:

system("DemoCabinet") {
    device("PLC1") {
        type = "PLC"
        model = "S7-1200"
    }
}

The IR example remains equally minimal and explicit:

data class Node(
    val id: String,
    val type: String,
    val props: Map<String, Any>
)

Beyond those preserved baseline artifacts, Kernel v0 must prove one minimal canonical connected example through the full pipeline:

system("DemoCabinet") {
    device("PLC1") {
        type = "PLC"
        model = "S7-1200"
    }
    device("M1") {
        type = "Motor"
    }
    connect("PLC1", "M1")
}

Its corresponding minimal IR/reference instance is:

nodes:
- Node(id="PLC1", type="PLC", props={"model": "S7-1200"})
- Node(id="M1", type="Motor", props={})

edges:
- Edge(from="PLC1", to="M1", type="connects")

Within this scope, the kernel may use a minimal ontology-aligned vocabulary for systems, devices, relationships, and properties, but it should not attempt to encode the full long-term domain model. The goal is a narrow executable slice, not a premature platform expansion.

Non-Goals

Kernel v0 is not a roadmap for the whole platform. It does not include EPLAN UI or KiCad UI work, because the kernel must prove semantic execution before any application-like surface is allowed to dominate the architecture.

It does not include 3D or OpenCascade integration. Geometry and layout systems may matter later, but they are not required to prove the first compiler path and would distract from the semantic core.

It does not include plugin ecosystems, full standards coverage, broad domain packs, or enterprise surfaces. Those require a stable core to attach to and should arrive only after the kernel has demonstrated a disciplined execution model.

MVP Pipeline

The MVP pipeline is deliberately linear and inspectable. A small authored DSL is lowered into canonical IR, the IR is evaluated by an explicit rule step, and the resulting state is exported into a downstream artifact. For v0, the canonical rule is Every connection endpoint must resolve to an existing device, and the canonical export artifact is a JSON serialization of the validated IR. Each stage must be visible enough that a reviewer can understand what changed between stages and why.

The DSL stage proves that engineering intent can be written in a constrained author-facing form. The IR stage proves that meaning can be represented canonically. The rule stage proves that execution belongs in explicit compiler logic rather than hidden application state. The export stage proves that outputs can be generated as compiled consequences of the same source model.

Deliverables

The first deliverable is a minimal DSL authoring path that can represent the canonical connected example exactly as defined above. The second is an IR model that preserves identity, type, properties, and the single connection needed to lower that example into a node-and-edge representation suitable for rule evaluation and export. The third is a rule step that evaluates the canonical Every connection endpoint must resolve to an existing device condition over that IR and emits a deterministic pass or failure result.

The final deliverable is a JSON export produced from that same pipeline for the canonical connected example. The export is intentionally narrow, but it must be concrete enough to show that downstream artifacts can be derived from the compiled model rather than authored separately.

Milestones

The first milestone is DSL -> IR: the canonical connected example lowers into a canonical representation without losing the two device identities or the connection between them. The second milestone is IR -> Rule: explicit rule logic operates over that representation and verifies that the PLC1 -> M1 connection endpoints both resolve to existing devices in the model. The third milestone is Rule -> Export: the pipeline emits the canonical JSON artifact derived from that evaluated model.

Completion of these milestones is more important than surface breadth. Kernel v0 should remain small, readable, and architecturally disciplined even if that means leaving many future concerns unimplemented.

Acceptance Criteria

Kernel v0 is accepted when a reviewer can trace the canonical connected example end to end through the full pipeline and see that each stage performs a distinct architectural role. The example must begin in the DSL, lower into the corresponding node-and-edge IR, pass through the canonical Every connection endpoint must resolve to an existing device rule for the PLC1 -> M1 connection, and produce the canonical JSON export without relying on hidden UI behavior.

The DSL and IR artifacts in this document must remain intact as canonical examples of the kernel boundary. The kernel must demonstrate that compiler execution is real, inspectable, and downstream-oriented, and that the first executable slice stays centered on semantic structure rather than on product breadth.

Compiler v1

Compiler v1 is the first product-facing release of the Engineering Compiler as a dependable service boundary. Its job is to make semantic compilation inspectable, deterministic, and useful across multiple downstream targets.

Objectives

Normalize authored input into canonical IR.
Execute explicit passes for validation, derivation, numbering, and rule evaluation.
Emit diagnostics with provenance.
Prepare target-ready outputs for renderers and integrations.

Product Shape

Compiler v1 should be usable from command-line and service contexts, with plugin-aware rule packs and exporter targets. The emphasis is reliability, reproducibility, and traceability rather than optimization sophistication.

Success Metric

The release is successful when one semantic model can generate multiple synchronized downstream artifacts while preserving one source of truth and one diagnostic trail.

Studio v1

Studio v1 is the first serious user-facing shell of EngineeringOS. It should make the semantic platform inspectable and operable without relocating authority from the compiler and IR into hidden UI state.

Objectives

Provide language and graph-oriented project inspection.
Expose diagnostics, compiler results, and generated outputs.
Support projection views such as schematic, BOM, or report-oriented surfaces.
Stay aligned with Kotlin Multiplatform, Compose Multiplatform, and WASM delivery goals.

Product Boundary

Studio v1 is not a drawing-first CAD clone. It is a semantic workstation for authoring, inspection, compilation, and projection.

Success Metric

The release is successful when users can understand and operate the semantic pipeline through Studio without losing the ability to explain every action at the language, IR, and compiler boundary.

Enterprise

The enterprise product layer should commercialize EngineeringOS without collapsing the public semantic core into a closed product. Its role is to provide managed organizational capability above the open architecture.

Objectives

Hosted collaboration and managed compilation.
Knowledge distribution, governance, and policy enforcement.
Audit, compliance, RBAC, tenancy, and integration controls.
Private plugin, rules, and library distribution for organizations.

Architectural Rule

Enterprise features should amplify the semantic core, not redefine it. If an enterprise workflow cannot be explained as governance, distribution, collaboration, or operations above the open platform, it is probably in the wrong layer.

Success Metric

The enterprise layer is successful when organizations adopt EngineeringOS because the open core is trustworthy and the commercial layer makes it operable at scale.

RFC-0001: Vision

Status: Draft
Area: Platform Doctrine

Proposal

Establish EngineeringOS as an open semantic infrastructure project where engineering language, ontology, IR, compiler logic, and governed knowledge become the canonical source of truth above downstream renderers and tool integrations.

Why It Exists

This RFC anchors every later technical proposal in the same platform thesis so the repository does not drift into disconnected tool work.

RFC-0002: Language

Status: Draft
Area: Authoring

Proposal

Define Engineering Language as the human-readable authoring layer that captures engineering intent in a constrained, reviewable form and lowers into canonical IR rather than acting as the final execution substrate itself.

Open Questions

How much of the first language surface should be embedded in Kotlin-hosted DSLs versus a standalone syntax?
Which semantic constructs must be first-class in v0?

RFC-0003: Ontology

Status: Draft
Area: Semantics

Proposal

Define the core ontology as the governed vocabulary for entities, relationships, constraints, behavior, and domain extension points. The ontology should remain small at the center and extensible at the edges.

Open Questions

Which abstractions belong in the universal core versus domain plugins?
How should standards mappings attach to ontology evolution?

RFC-0004: IR

Status: Draft
Area: Canonical Representation

Proposal

Define Engineering IR as the canonical graph-oriented representation of engineering instances with stable identity, typed relationships, explicit constraints, and compiler-ready semantics.

Open Questions

What is the minimal canonical shape for Kernel v0?
When, if ever, does EngineeringOS need more than one IR tier?

RFC-0005: Compiler

Status: Draft
Area: Execution

Proposal

Define the Engineering Compiler as an explicit pass pipeline over canonical IR, covering normalization, validation, rule execution, derivation, diagnostics, and target preparation.

Open Questions

Which passes are mandatory in the first public compiler contract?
How should plugin-contributed passes declare ordering and compatibility?

RFC-0006: Plugin

Status: Draft
Area: Extensibility

Proposal

Define a plugin model for renderers, importers, exporters, rules, standards packs, AI workflows, language surfaces, and knowledge extensions without letting those extensions bypass semantic governance.

Open Questions

What compatibility model should plugins declare?
Which extension classes are safe in v1, and which should remain internal first?

RFC-0007: AI

Status: Draft
Area: AI Architecture

Proposal

Define AI as a bounded proposal and transformation layer over language, IR, ontology growth, and standards extraction while preserving human and compiler authority over accepted engineering meaning.

Open Questions

Which AI actions may auto-apply to local drafts and which always require review?
How should provenance be preserved for knowledge extraction and semantic edits?

RFC-0008: Knowledge

Status: Draft
Area: Standards And Knowledge

Proposal

Define the Knowledge Compiler path that turns standards documents, manufacturer references, and reviewed AI extractions into governed ontology additions, rules, and mappings that the project compiler can consume.

Open Questions

How should evidence be attached to extracted rules and concepts?
What review workflow promotes candidate knowledge into governed knowledge?

Standards

The standards perimeter around EngineeringOS is broader than one format family. The draft repeatedly points to AutomationML, OPC UA, SysML v2, IFC, and IEC CIM as important external references, along with the broader world of IEC, ISO, UL, and regional standards that must eventually feed the knowledge layer.

How Standards Are Used

EngineeringOS should use standards in three ways:

as ontology references for defining durable semantic concepts;
as rule sources for compiler and knowledge-pack behavior;
as importer and exporter boundaries where industrial interoperability is required.

What Standards Are Not

Standards should not be copied blindly into the internal model. They must be mapped, reviewed, and governed through the knowledge path so the platform remains coherent even when standards overlap, conflict, or evolve at different speeds.

Papers

EngineeringOS should be informed by literature on compilers, knowledge representation, ontology engineering, graph-based modeling, model-driven systems engineering, and AI-assisted extraction. The repository does not yet maintain a formal bibliography, but the conceptual sources are already clear.

Research Themes

compiler passes, IR design, and target lowering;
ontology and knowledge-graph design for engineering semantics;
standards extraction and evidence-preserving review loops;
model-based and systems-engineering representation strategies;
collaborative governance for open technical infrastructure.

Repository Role

This document is the placeholder for a more rigorous paper list. Its purpose is to keep the manifesto honest about the fact that EngineeringOS is building on an existing body of research, not inventing every concept from nothing.

Ecosystem

The draft's leverage perimeter includes more than the headline platforms. The ecosystem reference should therefore remain explicit about both software assets and method references.

Direct And Indirect References

Geometry and mechanical perimeter: OCCT, FreeCAD, OpenSCAD.
Electrical and PCB perimeter: QElectroTech, KiCad, LibrePCB.
Industrial and semantic standards perimeter: AutomationML, OPC UA, SysML v2, IFC, IEC CIM.
Compiler and tooling perimeter: LLVM, MLIR, ANTLR, Tree-sitter, LSP.
Storage, analytics, and graph perimeter: SQLite, DuckDB, Neo4j.
UI and runtime perimeter: Kotlin Multiplatform, Compose Multiplatform, WASM, Skia, WebGPU.
Visualization and digital-twin perimeter: OpenUSD, Blender, OpenBOM.
Governance and project-structure references: Kubernetes, Git, Rust, Linux Foundation, Apache-style open project structure.

Method Reminder

Every ecosystem item should be tagged by method: direct use, integration, study, or standards reference. That method classification is part of the architecture, not editorial decoration.