About

We think the operator should own the record

Operators increasingly deploy heterogeneous systems from many vendors, and each one arrives with its own idea of what an event is and how long it lives. We are building the layer underneath.

What we believe

Principles we are willing to be held to

Portability is the product

Customer retrieval, export and interoperability are core features, not concessions. If our position depended on trapping your data, the ownership claim would be marketing.

Open the language

PhyUDM stays Apache-2.0 and independently implementable. External adoption validates the standard and lowers connector costs for everyone, including us.

Privacy by design

Collection, retention, purpose and access are explicit and auditable. Necessity, proportionality and purpose limitation are product constraints, not a policy page.

Say what is true

We describe security work as roadmap or verified — never as certification we have not obtained for the deployment in question.
Positioning

Things we will not claim

Every one of these is a message we have explicitly ruled out. Holding a vendor to their own stated non-goals is a reasonable thing for a buyer to do.

  • Storing everything forever
  • Copying every connected vendor record
  • Replacing the operational systems you already run
  • Undefined “AI-powered” promises
  • Claiming compliance we have not verified
  • Treating the dashboard as the platform
Ecosystem

We would rather coexist than displace

Build and debug with the tools your engineering team already prefers. Operate and retain the cross-vendor record in PhyCloud. Those are different jobs, and pretending otherwise helps nobody.

Talk to us

We are looking for design partners, not pilots-in-name-only. If you can describe a workflow where cross-system timing matters, we would like to hear about it.

business@phyware.io

Follow the work

PhyUDM development happens in the open, and we write about the trust and data-provenance problems we keep running into.