How {yourcompany}os Works: Process Layer, Implementation Layer, Open Schema

A new project starts. Someone types the name into the ERP. Someone else creates the folder in SharePoint. A third person sets up the mailbox, and the plans land in the CDE. Five systems, all of them working fine on their own, none of them aware that they are describing the same project. Nobody chose this. It is what happens when every tool keeps its own copy of the truth and people are the integration layer between them.

{yourcompany}os is the layer that sits on top of that stack and glues it together. It does not replace your ERP, your storage, your mail, or your specialist tools. It runs the process across them, so the project exists once as a process, and each system gets told what it needs to know.

Underneath, that separation is deliberate: the process, the systems it talks to, and the data model are three independent layers rather than one bundle. This article walks through what each layer does, what it saves you, and how the three behave when a tool in your stack changes.

What stays, and what actually changes

Stays exactly as it is	What changes
Your ERP, CRM, storage, mail, and CDE	One process spans them, instead of a person carrying work between them
The tools people already know	Tasks arrive in the existing inbox and filing system, not in another UI to learn
Where your files live	Which version is current is answered by the process, not by a naming convention
IFC as your exchange format	A workflow schema sits on top of it so applications can query and validate

The practical payoff of being a layer rather than a platform: there is no migration project. Nothing has to be moved out of the systems it lives in before the first process can run, which is why a first core process goes live in 1-2 days instead of after a rollout. Nobody has to be retrained onto a new interface, because work is delivered into the tools they already open every morning. And when the one person who knew all the steps goes on holiday or leaves, the steps are still in the process rather than in their head.

The three layers

Layer	What it is	What it buys you
Process	BPMN definitions your team authors and owns	The workflow survives tool changes and staff turnover, and stays auditable
Implementation	One connector per capability group (storage, ERP, email, AI, checkout, ...)	Swapping a vendor is a configuration change, not a re-engineering project
Data model	The open schema entities and processes read and write against	You can inspect and export your own data without asking permission

Most workflow tools collapse these into one thing: the "flow" is the integration is the data structure, all defined in the same no-code canvas, and all lost together if you switch vendors. {yourcompany}os keeps them as three independently replaceable parts, which is exactly what makes it safe to bolt onto a stack you have already invested in.

Layer 1: Process - the part that outlives your tools

A process in {yourcompany}os is a BPMN definition, not a flow run. That distinction sounds academic until a tool changes. A "flow run" (Power Automate, Zapier, most iPaaS tools) is a single execution that starts, does its thing, and ends. It has no memory of itself as an entity, so the moment a project spans weeks and several handovers, there is nothing durable to point at. A BPMN process definition is an artifact: it has phases, subprocesses, gateways, and a lifecycle that outlives any single execution.

What that gives you day to day:

• One project identity instead of five. Naming, ERP registration (in SAP or bexio, for example), setup, execution, and closure are phases of one process, each touching different systems but all pointing back to the same project. That is the copy-paste problem from the opening, solved structurally. See the full breakdown in Create Project: One Stable Anchor Across Your Tools.
• Long work does not fall apart at handovers. Setup and delivery run as their own subprocesses across tools, but they remain phases of the parent process rather than standalone scripts that terminate and forget.
• AI helps without being in charge. An agent can research, classify, or draft inside a step; gateways and people still decide what happens next, and every step is logged. Useful when you need to explain to a client or an auditor why something was approved. More detail in How to Operate Agentic AI in a Business Context.
• You can read your own process. Because it is BPMN rather than proprietary flow JSON buried in a SaaS canvas, the definition is legible and portable, and a new employee can look at the diagram instead of asking around.

Replace an ERP, a storage provider, or a viewer, and the process definition does not change. Only the implementation resolved underneath it does, which is the next layer.

Layer 2: Implementations - where the glue actually happens

A process step never names a vendor. It names a capability group, and exactly one implementation is configured to fulfil that group. Capability groups are things like storage, email, ERP and accounting, CDE, plan viewing, BIM, AI, or checkout. During onboarding you point each required group at whatever you already run, and the process logic is identical regardless of what you picked.

Currently available implementations by group:

• Storage: Nextcloud, Google Drive, Microsoft 365 (SharePoint or OneDrive via Microsoft Graph)
• Email: Outlook / Microsoft 365, Gmail, Nuntly (for project inboxes and system delivery)
• ERP / accounting: bexio (addresses, ERP, accounting)
• CDE: Trimble Connect
• Plan viewing / BIM: internal engine or iolabs (plan viewer), abstractBIM (BIM and IFC)
• AI: Infomaniak AI (Swiss hosting, default), OpenAI, Anthropic, Google Gemini, or your own model as a BYO LLM
• Checkout / payments: Stripe

Full mechanics are in Implementations: Connect Customer Systems.

Two things follow from this, and both are the kind of thing you only appreciate two years in:

1. Swapping a system is a configuration change, not a re-engineering project. Your company moves from Nextcloud to SharePoint, or switches AI provider because of a pricing change. The process that consumes "storage" or "AI" as a capability keeps running untouched. Compare that to a no-code flow where the vendor is wired into every node.
2. A missing system is additive, not blocking. If something in your stack has no implementation yet, one gets added for that capability group without redesigning the process that will use it. In practice this is scoped through a Discovery Sprint (from CHF 6'000): the new implementation is built and wired to the relevant process within 1-2 days, not as a separate integration project with its own budget round.

Which answers the question every technical evaluator asks in the first ten minutes, so it is worth stating plainly:

Does {yourcompany}os replace my ERP? No. Your ERP, CRM, email, and specialist tools stay where they are, and the people who use them keep using them. {yourcompany}os connects to them as implementations and orchestrates the steps between them. It is an orchestration layer next to your ERP, not a competitor to it.

Layer 3: Data model - open schema, no login

The schema behind {yourcompany}os is published as the Pragmatic Data Contract, browsable at schema.pragmaticbim.ch with no account required. You can inspect classes, relations, and versioned releases before you integrate or commit to anything, which is the opposite of a data model you only see after a sales call.

Why that matters to you rather than to us:

• Meaning carries between tools. Entities such as projects, spaces, requirements, changes, and process objects share a stable public schema URI and graph relations, so the same project means the same thing across {yourcompany}os, iterthink, and anything else built on the contract, instead of being re-encoded as proprietary columns in every system.
• You can improve it. The schema lives on GitHub as the Pragmatic BIM Data Contract. File issues, propose entities, open pull requests. If your industry needs a concept that is missing, you are not waiting on one vendor's private roadmap.
• Exit is inspectable, not theoretical. Because the schema is public and versioned, you can audit it before you commit, plan a migration path, and export against a version you can pin. You know what "your data" is structurally, in advance, instead of discovering it during a contract dispute.

Full detail is in Open Schema Instead of a Black-Box Database. One clarification worth making: this is not an IFC replacement. IFC stays the exchange format, and the schema is a workflow-oriented contract layered on top of it so applications can query, validate, and automate without re-deriving IFC logic every time.

How the three layers interact: a worked trace

Take the event from the opening, "a new project is created," and follow it through all three layers.

1. The process fires. The Create Project definition starts and assigns a project name and identity. Defined once, in BPMN, and unchanged by whatever tools sit behind it.
2. It reaches the ERP registration step. That step declares a dependency on the "ERP / accounting" capability group, not on a specific vendor.
3. The configured implementation resolves it. If your implementation for that group is bexio, the step executes against the bexio API. Point the group somewhere else and the same step resolves differently, with the process definition untouched.
4. The result is written against the open schema. The project entity, its identity, and its relations are persisted as published contract classes rather than an opaque row in a vendor table, so every other product and integration on that schema can address the same project the same way.
5. Setup and closure continue on the same spine. Each subprocess resolves whichever capability groups it needs (storage for documents, mail for notifications) while still referring to the one project identity created in step 1.

Compare that with the version you probably run today, where step 1 is a person typing a name in five places and steps 2 to 5 are a chat thread. Nothing in the trace couples the process to a vendor, and nothing hides the resulting data behind a login. Each layer can change without dragging the others with it.

Why the layers are separated this way

The structure is deliberately the inverse of a closed-ontology platform. A system like Palantir Foundry keeps its ontology proprietary, because the ontology is the lock-in. {yourcompany}os publishes the schema openly and treats your process definitions, not the schema, as the thing you own and refine. Your competitive edge was never the data model; it is how your company actually runs. The full comparison, including pricing and delivery-model differences, is in How {yourcompany}os Brings the Palantir Model to SMEs.

FAQ

Does {yourcompany}os replace my ERP?
No. Your ERP (SAP or bexio, for example) stays in place as one implementation behind the "ERP" capability group. {yourcompany}os orchestrates the steps around it and does not take over ERP functions.

Do we have to migrate data or retrain people before we start?
No. That is the point of being a layer rather than a platform. Data stays in the systems that own it, and tasks are delivered into the inbox and filing system people already use, which is why a first process can go live in 1-2 days.

Can I self-host or run this on my own infrastructure?
Swiss hosting is the default operating mode. Because the schema is public and versioned, you can inspect and plan for data portability independent of hosting location.

What happens to our data if we leave?
Because the data model is published and versioned rather than proprietary, you export against a schema you already understand and have audited, instead of negotiating an export format after the fact.

How is this different from an iPaaS like n8n or Zapier?
iPaaS tools are strong at short-lived connections between apps but weaken as a process grows phases, subprocesses, and governance, because the "workflow" and the "process" are the same disposable object. {yourcompany}os keeps the process as a durable, versioned definition and the integrations as separately swappable implementations underneath it.

Where is the schema source of truth?
schema.pragmaticbim.ch for the live reference and versioned snapshots, with the underlying contract maintained openly on GitHub as the Pragmatic BIM Data Contract.

What if a system we use has no implementation yet?
A new implementation can be added for that capability group without redesigning the process that depends on it, including connecting your own LLM as a BYO implementation for the AI group. This is scoped through a Discovery Sprint (from CHF 6'000, 1-2 days), the same mechanism used to bring a first process live.