One clearer view of the campus systems that matter.
MTRX is a campus technology approach for institutions seeking better context across selected places, assets, data sources and operational workflows. The solution is defined around the decisions you need to support and the systems you already use.
Platform principles
Five working principles shape how every MTRX engagement is scoped.
Start with the use case
Define the question before choosing tools.
Connect deliberately
Assess systems, interfaces, data quality and permissions before committing to integration.
Model what matters
Use digital representations where they create operational or planning value.
Make information actionable
Design views around user roles and decisions, not just data volume.
Govern from the beginning
Define ownership, access, updates, security and change management.
Conceptual capability layers
Each layer raises questions that must be answered before it is built. This is a conceptual model, not a product screenshot.
| Layer | Purpose | Questions to resolve |
|---|---|---|
| Data sources | Existing campus systems, models, documents, sensors and datasets. | What exists? Who owns it? Can it be accessed and used? |
| Integration and data preparation | Connect and prepare selected data where technically and contractually feasible. | Which APIs, formats, refresh rates and quality controls are needed? |
| Digital representation | Represent selected buildings, places, assets or systems in a suitable model or view. | What level of fidelity is useful for the agreed use case? |
| Operational intelligence | Dashboards, alerts, reports or decision-support views, where included. | Which decisions, thresholds and actions matter? |
| People and governance | Roles, permissions, review, maintenance and ongoing ownership. | Who is responsible for data, decisions and changes? |
What a discovery session produces
- A summary of the problem and intended outcomes.
- A preliminary inventory of systems, models and data sources.
- Known access, privacy, security and integration constraints.
- A proposed pilot scope and acceptance criteria.
- An indicative delivery approach and next-step estimate, subject to validation.
How we label capabilities
Conceptual
An idea or diagram that explains an approach. It is not a product feature and not a promise.
Subject to assessment
Possible for some environments. Feasibility depends on data, interfaces, permissions and security review.
Confirmed in scope
Agreed in writing for a specific project, with assumptions, exclusions and acceptance criteria.
Scope note. Capabilities and delivery scope are confirmed after technical assessment.
Let’s map the next useful step for your campus.
Tell us what you want to understand, connect or improve. We’ll use the first conversation to assess fit and identify a sensible next step.