The connected organisational model

Understand how your organisation fits together.

Connect your people, processes, applications and infrastructure with the costs and risks behind them. Follow the relationships to see what a change could affect.

ClaudeMicrosoft 365 CopilotOther MCP clients

One graph. Many lenses. Each discipline looks at the same organisation from a different angle. How STATE3 stays current →

The picture extends across your organisation.

The five lenses read one model. It connects twelve kinds of knowledge, from people and processes to contracts and locations.

01 · The problem

You already have this information. It just isn't connected.

Most organisations we work with aren't missing data. They have an application list in a spreadsheet, a CMDB that was accurate at go-live, architecture diagrams from the last programme, contracts in a finance system, risks in a register, and a good deal of context that exists only in the heads of four or five long-serving people.

Each of those is a reasonable record of one thing. None of them records how any of it relates. So when someone asks what a change will affect, the work starts again: find the right people, check whether the spreadsheet is current, draw the diagram on a whiteboard, and hope nothing was missed.

Collecting another list of applications doesn't fix that. The hard part is knowing how they connect to everything else.

02 · What it connects

Twelve kinds of knowledge in one model.

STATE3 holds the records most organisations keep in separate places, along with the relationships between them. The twelve groups are a way to describe the model, and each one is listed under the picture.

Illustration of twelve knowledge domains, each connected to one STATE3 model at the centre. The domains are listed after the image.
Conceptual illustration. Select it to open the full-size image.
People & organisation
People, roles, owners, business units and responsibilities.
Capabilities
Business and technology capabilities, their hierarchies, and the applications and activities that support them.
Processes & activities
Business activities, process steps, events and who is responsible for each.
Data & knowledge
Data entities, fields, classifications, the business glossary and how data relates.
Applications
Applications, components, endpoints, criticality and ownership.
Technology & infrastructure
Servers, network details, cloud resources, environments and deployments.
Vendors, contracts & costs
Suppliers, agreements, licences, expiry dates and linked costs.
Risk & governance
Risks, owners, treatments, architecture principles, assessments and approvals.
Integrations
System connections, protocols, frequency and the data exchanged.
Services
Business and IT services, linked to the applications and infrastructure that support them.
Change & lifecycles
Requests, change impact, technology lifecycles, and current, future and what-if workspaces.
Locations & sites
Locations and the places technology runs.

AI assistants are a way to query the model, so they are not one of the twelve: see how MCP access works.

03 · In the product

What it looks like in STATE3 Enterprise.

Three screens from STATE3 Enterprise, taken in an example local government workspace. The data in them is sample data.

See what a change could affect.

Choose a system and follow its direct and indirect dependencies. In this example an ERP application is selected, and the panel beside the diagram lists what is affected if it fails, one step out and then two.

request and change management
Example dependency analysis for an ERP application, with connected systems and dependency details.
Dependency analysis. Select it to open the full-size screen.

The applications you run, and how critical each is.

The application inventory lists each application with its type and its business criticality.

application portfolio management
Example application inventory showing application types and business criticality.
Application inventory. Select it to open the full-size screen.

Contract expiry dates on a timeline.

Each vendor contract is placed at its expiry date, so you can see which renewals are coming and when.

IT financial management
Example timeline of vendor contract expiry dates.
Contract timeline. Select it to open the full-size screen.
04 · What STATE3 means

Three states. One destination.

Most organisations do not know the state of their own technology in any complete way. Getting from invisible to understood is why STATE3 exists, and where the name comes from.

State 1

Invisible

In people's heads. Lives in spreadsheets, vendor portals, tribal knowledge.
State 2

Visible

Documented but static. Diagrams that go stale the day they ship.
State 3

Understood

Live and queryable. People and AI assistants can ask it questions and act on the answers.

Most organisations are stuck at State 1 or State 2.

STATE3 is the destination.
05 · What you can ask

The questions that are hard to answer today.

None of these is a hard question. Each is hard to answer because the answer is spread across six systems and several people's memory. STATE3 holds the connections, so each one becomes something you look up.

Which applications support this business process?

Answered byAPM

Which contracts expire in the next 90 days?

Answered byITFM

Where are we running unsupported technology?

Answered byAPMRisk

Which risks are attached to this application?

Answered byRisk

Which applications have no clear owner?

Answered byAPM

The questions change with who is asking: see them for IT operations and for CIOs. You can also ask them in plain English through an AI assistant over MCP.

06 · Keeping it current

A model is only useful if it is still true.

Every CMDB you have used drifted. Ours would too, if the only thing keeping it current was people remembering to update it. So STATE3 takes information from three directions and treats them differently: scheduled connectors pull from source systems that already know the answer, bulk import covers what no connector reaches, and people edit directly where judgement is needed. Once a person has edited a field, automation does not overwrite it. STATE3 records where each fact came from and when it was last confirmed.

Your data apps · vendors · people STATE3 always current Your AI via MCP · plain English
Built for councils, government, tertiary institutions, primary industries, and ports and logistics
07 · AI access

Your assistant knows how to reason. It does not know your organisation.

An AI assistant can write a decent migration plan. It cannot tell you what your migration would affect, because it has never seen your estate. STATE3 already holds that context, and the STATE3 MCP server lets an authorised AI client ask questions of it.

The context stays in STATE3.

The model is not given a copy of your organisation. It asks STATE3, and STATE3 answers within the permissions that user already has, so the organisational knowledge stays where it is governed. We backed MCP because it is an open standard: whatever your team uses this year, and whatever replaces it, connects the same way. The exchange on the right illustrates the kind of question an AI client can put to STATE3, and what the answer looks like.

Claude Microsoft 365 Copilot other MCP clients with Entra ID sign-in
Example · Claude → STATE3 via MCP
What would break if we decommissioned the AD domain controller?
lookingchecking dependencies, up to five hops out…
CriticalFinance ERP · Payroll · SSO Activities14 business activities affected Risks7 open · 3 untreated Request2 in-flight change requests Contracts5 vendor contracts linked
08 · Who this is for

Built for organisations where someone has to justify the decision.

Renewals, audits, ministerial questions, mid-flight change programmes. The common thread is that decisions have to be explained to someone who was not in the room, whatever the size of the organisation.

Local councils

Ratepayer money is finite and the spend is public. See what a system costs, what it supports and what replacing it would involve before the question is asked at a council meeting.

Central government

Ministerial questions arrive with hours of notice. “What depends on what” becomes something you look up rather than convene a meeting about.

Tertiary institutions

Federated faculties, decentralised IT, and nobody holding the whole picture. STATE3 keeps that picture current as departments reorganise around it.

Primary industries

Operational technology and corporate IT run on different assumptions. STATE3 maps where they meet, so neither side is surprised by the other’s change.

Ports & logistics

Continuous operation and no real maintenance window. Impact has to be understood before the change is scheduled, not during it.

What changes, whatever the sector:

Today
→
With STATE3
Renewals arrive without warning. Costs creep year over year.
→
Spend defensible to the dollar. Contracts priced months in advance.
Knowledge walks out the door when a senior person leaves.
→
The next person sees the same picture. Ownership and dependencies live in the graph, not in someone's head.
Audit prep starts from scratch each time. A quarter spent before the first question arrives.
→
The evidence is already assembled. Ownership, dependencies and contracts are in one place when the auditor asks.
Change projects stall waiting for impact assessments nobody trusts.
→
No upstream surprises. Run the impact in seconds, five hops out, scored by criticality.
09 · Getting started

How an engagement usually starts.

1

Discovery call

We talk through your goals and the specific problems in your environment. About 30 minutes.

2

Tailored demo

We show STATE3 Enterprise on data shaped like yours, so you can see how it would work for you.

3

Proof of value

A short, scoped engagement using your real data, so you can judge it on your own estate rather than a demo dataset.

Talk to us about your estate.

A 30-minute call, and we will tell you whether STATE3 fits what you are dealing with.