AI on your organisation's reality

Your AI had plenty to read.
Nothing to reason with.

Thousands of pages in SharePoint and Confluence describe your organisation. None of them state how it works — not in a form an agent can query, traverse, or be held to afterwards. Nodwise is that form: a typed model of your organisation, and the live graph of everything in it.

Open the demo See the metamodel

Pre-launch. The demo tenant is open — one click with your work account, no sales call.

The formula

Metamodel + instance graph + AI.

Three parts. Take away any one of them and you are back to a pilot that demos well and dies on contact with the real organisation.

The metamodel

The grammar

What kinds of things exist, how they may relate, what states they can be in. Closed on purpose — a closed grammar does not just describe, it constrains what an agent is able to assert.

+

The instance graph

The facts

Your systems, processes, people, datasets and obligations as they are today — each a typed node with an owner, a lifecycle state, and real edges.

+

AI

The consumer

Agents stop summarising documents and start traversing your organisation. The answer arrives as a path, not a paraphrase — and they watch.

Why it kept failing

Retrieval finds the closest paragraph. You needed the actual relationship.

Search over documents returns the most similar passage, and similarity is not truth. A document says what one person believed on the day they wrote it. A model states what is true now — and knows when it changed.

A paragraph also has no owner, no lifecycle and no edges. An agent can read it and still not know who to ask, what breaks if it changes, or whether it was superseded two reorganisations ago.

Ask a document store how many pages mention this system and it will answer. Ask it which processes have no owner — and it has nothing to compute with.

That second question is the one your business actually asks.

Ask the graph

If Victory Bikes fails, which customers are affected?

Impact simulation

Victory Bikes

Re-run traversal

Typed path

5 hops

Contract Register · Product Catalog · Operational Register

Victory Bikes

External Entity · Partner & Supplier

has party ←

Supply of Touring Tire Tube

Governance & Compliance · Agreement

is subject to ←

Touring Tire Tube

Physical Assets · Inventory & Material

depends on ←

SO70282

Business · Commercial Interaction

is placed by →

Dalton Adams

External Entity · Customer

impacted customer

Purchasing knew the supplier and the contract. Operations knew which SKU it goes into. Sales knew who ordered it. Three functions, three registers, three systems — and nobody owned the chain. Answering this in most organisations is a week of email. In the model it is one typed path, and the answer is a named customer.

Note what comes with it: the path itself. You are not deciding whether to trust a sentence — you are looking at the four edges the answer was made of. And the model carries the nuance too: a second supplier holds a contract for the same component, so this is a disruption to reroute, not a line that stops. A document store gives you three plausible paragraphs and no way to check either claim.

How it works

A week to an environment. Agents on it before the model is finished.

01

Activate the environment

A dedicated tenant with its own database and its own context. About a week — it is provisioning, not a programme.

02

Read your systems in

Remote Services run inside your network and dial out — no inbound port, no firewall exception. Start with one domain: every node is independently lifecycle-managed, so the model grows instead of blocking on completeness.

03

Point your agents at the model

They query it in plain language and traverse it by type. A partial model already answers questions a complete document store never could — because the part that exists is typed.

The failure mode

An agent that can't read your organisation will invent it — convincingly.

That is the dangerous part. A wrong answer that sounds wrong gets caught. A wrong answer assembled from three real paragraphs, in your own vocabulary, with the right tone, gets forwarded — and then acted on.

Grounding is not a prompt technique. It is a data structure: a closed grammar the agent cannot step outside of, and a graph of facts it has to traverse to say anything at all.

The same structure surfaces what nobody had written down — like the critical task only one person on the team knows how to run.

Business continuity, in depth →

Trust

The architecture diagram and the governance register, the same object.

Every node carries lifecycle, ownership and lineage — as part of the node, not in a parallel register somebody maintains after the fact.

That is what lets an agent be proactive rather than merely responsive.

Autonomy of attention, not of authority. In a regulated organisation, an agent that changes things on its own is premature, and we are not going to pretend otherwise. An agent that sees before you do is not.

None of that is possible over documents. A paragraph has no owner to escalate to, and no state in which a change could be detected.

Isolation is per-database, not per-row — and the audit of what the agent saw before it raised the flag is a query against the same graph.

what the agent raises

A process lost its owner

Escalated to the accountable role — because the model knows who that is.

A control drifted from its policy

The edge still exists; the states no longer agree.

A critical task rests on one person

Nobody wrote it down. The graph shows it anyway.

We already have a RAG chatbot over our documents. How is this different?

Retrieval finds text similar to your question. Nodwise answers by traversing typed relationships, so the reply carries the path it was derived from. The two are complementary: documents are good evidence, a model is a good structure. The failure you have been hitting is structural, not a retrieval-tuning problem.

Do we have to model everything before agents are useful?

No — and a partial typed model already answers questions a complete untyped repository cannot. Start with one domain. Every node and relationship is independently lifecycle-managed, so the model grows with the organisation.

How is this different from a data catalog?

Catalogs describe what data exists. Nodwise describes how the organisation works — systems, processes, people and obligations as typed nodes, with relationships and lifecycle as first-class citizens. The catalog view is one perspective on top, not the foundation.

What about regulated industries — finance, pharma, healthcare?

Isolation is per-database, not per-row. Combined with lifecycle, lineage and ownership on every node, an audit trail is a query rather than a separate system — including an audit of what an agent saw before it raised a flag. And to be explicit: agents here identify, report, monitor and escalate. They do not change your organisation on their own.

Where we are

Pre-launch, and saying so.

Nodwise has no customer logos to show you, and we are not going to borrow anyone's. What we have is checkable without talking to us: a demo tenant with a fully modelled organisation you can open right now, a metamodel you can read end to end, and architecture claims you can verify — isolation per database, and Remote Services that never need an inbound connection.

see it

Open the demo

A fully modelled organisation, one click with your work account. No form, no call.

Open the demo

build it with us

Design Partner Program

An environment instantiated for your organisation, your own data in the model, a solutions architect modelling your first dimension alongside your team, and direct input into the roadmap. A limited group, in this early phase.

Apply to the program