Semco Maritime × QAECY · 28 October 2026
Graphs, the Cue Index ,
Point: a day about how connected data works, how Cue builds it, and what keeps it safe. Today is as much about listening as presenting.
Say: "Thank you for having us." Introduce the team in one line each. Then frame the day: "Today has three movements. We show you what we do, you show us your world, and then we work on the ship framework together. The slides are deliberately light, so please interrupt: the questions are the best part."
Remember: the educational block comes after Semco has shown their world. From then on, use their words and their examples instead of ours wherever you can.
Today
Agenda
Together
QAECY
Inspire Next
QAECY
Tech intro : from chatbots to agents, and the context layer
Educate
Semco
Listen
QAECY
Educate
QAECY
Inspiration : service briefings, and logistics with Loglay
Inspire
Together
Work
Together
Up next: Cue in action. The first column is who leads each part. Each linked item jumps to its section; this agenda comes back between sessions.
QAECY
Cue in action
Reference clients and a glimpse of BIM+
Placeholder: switch to the Cue in action material.
Today
Agenda
Together
QAECY
Inspire
QAECY
Tech intro : from chatbots to agents, and the context layer
Educate Next
Semco
Listen
QAECY
Educate
QAECY
Inspiration : service briefings, and logistics with Loglay
Inspire
Together
Work
Together
Tech intro
From chatbotsagents
Point: 10 to 15 minutes of framing: what changed in AI in three years, what is still missing, and why that missing piece is what Cue builds.
Say: "Before Semco shows us your world, a short tour of ours: where the technology is, and where we think the hard problem has moved to."
Tech intro · Where we're coming from
From chat to agents
2022 Chat
2023 Tools & search
2024 MCP
2025 → Agents
Model
same for everyone
Your data
Tools
Memory
Permissions
Guardrails
Audit trail
Planning
The harness
where the difference is made
Point: the model has become a commodity. What surrounds it, the harness, and above all what data it can reach, is where the difference is.
Say, along the timeline:
2022, Chat. ChatGPT launches on 30 November 2022. A model that only knows what it learned in training. Clever, but sealed off: it knows nothing about your turbines.2023, Tools & search. Function calling and retrieval (RAG). The model can look things up and call a calculator or an API. Answers start to cite sources.2024, MCP. On 25 November 2024 Anthropic publishes the Model Context Protocol: one open standard for connecting any model to any tool or data source. Think USB-C for AI. OpenAI, Google and Microsoft adopted it within months; it is now governed under the Linux Foundation.2025 onwards, Agents. The model works in a loop: plan, call a tool, check the result, act. Claude Code, GitHub Copilot's agent mode, OpenAI Codex. Multi-step work, not just answers.
Click (harness): "In the middle is the model. Everyone rents the same handful, by the token, and they improve every few months. Around it is the harness: tools, memory, permissions, guardrails, audit trail, planning. And at the top, the one that matters most: your data. A brilliant model with no access to your world is a brilliant stranger."
Invite the room: "Does this match what you've seen in your own experiments?"
Bridge: "So if the model is a commodity, what happens to building software?"
Tech intro · What changed
Building an app is no longer the hard part
month 1 2 3 4 5 6
Until recently
Specify
Vendor & contract
Build
Roll out
one system, and you bend to it
Now
Dashboard
Form
Report
Assistant
v2
v2
Dashboard
v3
one sentence each, changed in the next conversation
If anyone can build the app, what it knows is the advantage.
Point: the interface has become cheap. The scarce thing is what the app can see, and whether its answers are right.
Say (top row): "This is how software used to arrive. Months of specification, a tender, a vendor, a build, a roll-out. Six months before anyone uses it, and then you bend your work to the system. Small needs never made the cut; they lived in spreadsheets."
Click (Now): "Today you describe what you want in a sentence and an agent writes working software. A dashboard on Monday, a form on Tuesday, a version 2 of the dashboard on Wednesday because someone asked for a filter. One app per team, if you like. Not a toy: real code that you can read, review and deploy."
Click (punchline): "So if anyone can build the app, the app is not the advantage. What it knows is." Pause on this. It is the thesis of the whole day.
Example to have ready: this deck itself, including the live SPARQL playground you'll see later, was built in conversation with an agent.
Note: the point isn't that in-house tools such as Mobi were wasted effort; it's that the next feature is cheap if the data underneath is good.
Bridge: "And that's exactly where it breaks down today."
Tech intro · The gap
Capable models. Little access to your world.
Anthropic · Nov 2024
"…constrained by their isolation from data ."
Gartner · Feb 2025
60 %
of AI projects abandoned without AI-ready data
MIT NANDA · Jul 2025
95 %
of GenAI pilotsno measurable return
The gap isn't intelligence. It's context.
Sources: anthropic.com/news/model-context-protocol · Gartner press release, 26 Feb 2025 · MIT NANDA, "The GenAI Divide: State of AI in Business 2025"
Point: there is a documented gap between what models can do and what they can reach. That gap, not intelligence, is why AI projects stall.
Say (quote): "When Anthropic launched MCP, they said it plainly: even the most sophisticated models are constrained by their isolation from data, trapped behind information silos and legacy systems. That's the model makers saying it, not us."
Click (60 %): Gartner, February 2025: through 2026, organisations will abandon 60 % of AI projects that aren't supported by AI-ready data. Same survey: 63 % of organisations either don't have, or aren't sure they have, the right data management practices for AI.
Click (95 %): MIT NANDA, "The GenAI Divide", July 2025: about 95 % of organisations saw no measurable P&L return from their generative AI pilots. The authors name the cause: tools that don't retain context, don't learn and don't fit the workflow. Not model quality.
Caveat, say it yourself before anyone else does: the MIT study is small (interviews, a survey of a few hundred people, public deployments) and was widely over-quoted. Use it for direction, not precision.
Click (punchline): "The gap isn't intelligence. It's context: your documents, your systems, your words."
Bridge: "So what would close that gap?"
Tech intro · The missing layer
A context layer under every agent
Cue Index
Documents
Systems
Your words
Models are rented. The context is yours.
Point: what closes the gap is a context layer: one place that holds your documents, your systems and your vocabulary, readable by any agent. That's what the Cue Index is.
Say (bottom up):
Documents. Specs, drawings, procedures, bulletins, e-mail, scans. Where most of the knowledge actually sits, and the hardest part to make usable.Systems. Configurator, engineering tools, ERP, Mobi, SCADA. They stay where they are. We connect to them; we don't replace them.Your words. RDS-PP codes, tag lists, document numbering, Danish, German and OEM speak, mapped to one vocabulary so "C03", "WTG-C03" and "mølle C3" are one thing.
"The hard and valuable work is building this middle layer. That's what part 02, after your session, is about."
Click (top row): "Once it exists, anything can read it: Claude, Copilot, the apps you build yourselves, partner tools. Over MCP for agents, an SDK for developers, and SPARQL for people who like to write queries."
Click (punchline): "Models are rented and replaceable. When a better one comes out next quarter, you switch the model, not the context. The context you build is yours, and that's where the value accumulates."
For IT: this is also an integration pattern: one shared model instead of point-to-point links between every pair of systems.
Tech intro · Agentic programming
Describe the app. The agent builds it on your context .
Build a dashboard of E&I progress per zone vs. plan for OSS-2. Flag zones more than 10 % behind and tell me why.
Zone WorkPackage ProgressReport
E&I progress · OSS-2 Week 33 · live
L1-A 100 / 100
L1-C 95 / 100
L2-A 86 / 80
L2-B 64 / 80
L2-C 72 / 75
L3-A 30 / 45
L3-B 22 / 20
L2-B: waiting for piping handover (6 open punch items).L3-A: cable trays late, PO 4500-2210, ETA week 35.
Illustrative
Point: proof of the last two slides. An agent builds a real app from one sentence, because the context layer already knows what a zone, a work package and a progress report are.
Say (the prompt): read the request out loud. "A project manager at the yard types this: build a dashboard of E and I progress per zone against plan for OSS-2, flag zones more than ten percent behind, and tell me why. No ticket, no specification."
Click through the four steps:
"First, the agent reads the model. Not table names: the things your business talks about, a zone, a work package, a progress report, and how they relate."
"Then it queries plan against actual for each zone."
"Then it looks for reasons. This is the part a dashboard tool can't do on its own: open punch items, late purchase orders, handovers. That's in documents and other systems, and the context layer links them."
"And it publishes the app for the yard team."
Click (dashboard): point at L2-B and L3-A in red, and read the reasons at the bottom: the piping handover with six open punch items, and cable trays held up by a late PO. "The answer comes with the why, and the why comes with a source."
Say: "Built in one conversation, changed in the next. And because the model underneath is shared, the next app starts where this one ended, rather than from zero."
Illustrative: OSS-2, the zones and the numbers are made up for the example.
Ask: "How close are your own experiments to this?" Let the room talk; it builds the bridge to Semco's session.
Bridge: end of tech intro. Hand over to Semco: "That's our side. Now we'd much rather hear yours."
Today
Agenda
Together
QAECY
Inspire
QAECY
Tech intro : from chatbots to agents, and the context layer
Educate
Semco
Listen Next
QAECY
Educate
QAECY
Inspiration : service briefings, and logistics with Loglay
Inspire
Together
Work
Together
Up next: Your world and perspectives.
Semco
Your world and perspectives
Semco presents
Placeholder: switch to the Your world and perspectives material.
Today
Agenda
Together
QAECY
Inspire
QAECY
Tech intro : from chatbots to agents, and the context layer
Educate
Semco
Listen
QAECY
Educate Next
QAECY
Inspiration : service briefings, and logistics with Loglay
Inspire
Together
Work
Together
Up next: Graphs, the Cue Index, security & compliance.
This session
Three parts, one vocabulary
Point: what the next hour is, and why: it gives us a shared vocabulary for the ship framework workshop this afternoon.
Say:
01 Graphs : things, how they relate and what they mean, and why that suits configurators, engineering data and turbine data alike.02 The Cue Index : how Cue reads documents and systems, recognises the things in them and connects them into one graph that people and agents can ask.03 Security & compliance : where the data lives, who sees what, and how it holds up to IT and to an audit.
Invite interruptions: "Please interrupt us. The best examples today are the ones you just showed us, so I'll keep pointing back to them."
Before you go on: note two or three concrete things Semco showed in their session (a system name, a code, a pain point). Reuse them on the next slides instead of our generic examples.
Your world
Five pictures of the same substation
Configurator MPT-1
Engineering TR-01
Work instructions T1 cooling
Turbine data =G014 MDA
Cost models MPT capex
exports · spreadsheets
e-mail
people's heads
Each system holds a piece. A graph holds the connections.
Point: every system in the room is right for its job. The connections between them are what nobody owns.
Adapt live: replace our labels with Semco's own words from their session. From what we have understood so far:
Configurator : options, rules and variants, working towards LOD4.Engineering : equipment, cables, signals and documents; Aveva- and Aucotec-style tools, and in-house systems.Work instructions : step by step for service technicians, in Mobi.Turbine data : SCADA, alarms, availability, failures.Cost models : the LCOE model, capex, opex, yield and lifetime.
Say (the highlighted names): "Look at the coloured tags. Each system has its own names for things. The main transformer is MPT-1 in the configurator, TR-01 in engineering, T1 in the work instruction and a capex line in the cost model. The turbine data speaks RDS-PP. All correct, all different."
Click (red lines): "So who connects them? Exports, mapping spreadsheets, e-mail. And mostly people: the colleague who just knows that MPT-1 and TR-01 are the same thing. That works until that person goes on holiday, changes jobs or retires."
Click (punchline): "Each system holds a piece of the picture. A graph holds the connections."
Note: this is not a criticism of any system. Each is right for its job; the point is the gaps between them.
Illustrative: the names on the tags are examples, not Semco's real codes.
Time
Applications come and go. The data stays.
Point: an offshore substation outlives three or four generations of every application around it. The data has to survive the tools.
Say (grey rows): "Each grey row is one kind of system: ERP, CRM, CAD and engineering, document control, maintenance. Each block is one generation of that software. Every red circle is a migration: data mapped, copied, and partly lost. Over thirty years that's a lot of red circles."
Click (blue bar): "The substation itself, and its data, runs straight through: design and build, energised, a retrofit, life extension, decommissioning. The people who need the data in 2046 are not the people who created it in 2026, and they'll be using different software."
Say: "So the question isn't which application is best today. It's whether your data and its meaning survive the next three switches. Open standards and a model you own are how they do. Including when the application you switch away from is ours."
Who: IT and anyone who has built their own system will recognise the migrations. Ask: "How many of you have lived through an ERP or PDM migration?" Usually most hands go up.
Bridge: "So let's look at what a graph actually is."
01
Graphs
Things, how they relate, and what they mean.
Point: about 20 minutes. First the basic idea (nodes, edges, facts, vocabulary), then why it suits Semco's data, then a live query.
Say: "Graphs. I'll keep this concrete: every example comes from turbines, substations and service, not from social networks."
01 What is a graph?
Things, and how they relate
has part
from batch
applies to
inspected
performed
took 2 h 15 min
OEM no. 4471-B · 2024
14 Mar 2026 · leak at segment 4
Turbine WTG C03 Component Pitch bearing B Batch Batch 7731 Bulletin SB-2026-14 Task Inspection Technician Anna K.
new kind of thing?
Point: a graph is the simplest possible data structure: dots and arrows. The arrows are what make it powerful.
Say (nodes only): "Six things. A turbine, WTG C03. One of its components, the pitch bearing on blade B. The production batch it came from. An OEM service bulletin. An inspection task, and the technician who did it, Anna. On their own, six rows in six different systems."
Click (edges): "Now the relations. The turbine has part the bearing. The bearing comes from batch 7731. The bulletin applies to that batch. The inspection inspected the bearing, and Anna performed it. Every edge is named and has a direction, and it is data in its own right. In a table world these are foreign keys in a join table, or more often: missing, because they live in different systems."
Click (properties): "Details hang on the nodes and on the edges: the OEM part number and year on the bearing, the date and the finding on the inspection, and on the 'performed' edge, how long it took. Properties on a relation are something tables find awkward."
Click (no fixed shape): "And if tomorrow you need a new kind of thing, a new kind of edge, you just add it. Nothing has to be migrated first. We'll come back to that."
Point at the path: follow bulletin → batch → bearing → turbine with your hand. "That path joins three of your worlds: an OEM bulletin, turbine data and a service task. That's the question a service planner actually has: which of my turbines does this bulletin affect, and has anyone looked at them?"
If asked "isn't this just a data model?": "Yes. But one where the relations are first-class, the vocabulary is shared and published, and identifiers work across systems. Next slide."
01 Knowledge graph 101
A fact is three things
Transformer T1
— must satisfy →
REQ-0412
FACTS
millions of them
applies to
must satisfy
WI-0231
T1
REQ-0412
T2
GIS bay 3 …
VOCABULARY
the ontology
applies to
must satisfy
Instruction
Equipment
Requirement
is a is a is a
Open W3C standards: RDF · OWL · SPARQL Portable: no lock-in
Point: knowledge graph 101 in one slide. A fact is a triple. Facts live in one layer, the vocabulary that gives them meaning lives in another, and both are open standards.
Say (the triple): "Every fact in a knowledge graph has the same shape: subject, predicate, object. Transformer T1, must satisfy, requirement REQ-0412. A sentence that a person can read and a machine can process. That's RDF, the W3C standard."
Say (bottom band): "Down here are the facts. Work instruction WI-0231 applies to T1, T1 must satisfy REQ-0412. In a real project there are millions of these, from every system and document, and each thing has exactly one identifier."
Click (vocabulary): "Up here is the vocabulary, the ontology. Not things but kinds of things: Instruction, Equipment, Requirement, and the relations allowed between them. Defined once, in Semco's terms."
Click (is a): "The dashed lines connect the two: T1 is an Equipment, and so are T2 and GIS bay 3. That link is what lets you ask about kinds of things instead of individual names. And it's what lets an AI agent understand what your data means without reading your table names."
Click (standards): "RDF for the facts, OWL for the vocabulary, SPARQL for queries. All W3C standards, the same body that standardises the web. Any compliant tool can read your graph. No lock-in, including to us."
If asked "isn't this just a data model?": "Yes, and that's the point. But one that is published, shared and machine-readable, where the vocabulary changes when your business changes, not when a vendor releases a new version, and where identifiers are global, not per database."
If asked about property graphs (Neo4j): property graphs are good for analytics inside one application; RDF is built for sharing meaning across systems and organisations: global identifiers, a standard vocabulary language, a standard query language. Cue uses RDF.
01 From configurator to lifecycle
A configuration is already a graph
In the configurator
Rules
3 × 270 MVA requires deck height ≥ 9.5 m
Max lift weight ≤ vessel capacity − 10 %
must satisfy
generates
costs
needs
limited by
failure rates feed back into the rules
Variant 3B
Requirements client spec, grid code
Engineering objects equipment, cables, signals
LCOE capex, opex, €/MWh
Work instructions service tasks, Mobi
Vessel lift capacity
Turbine & asset data
Point: a configuration is already a graph. The configurator just keeps it to itself. Put the chosen variant in a shared graph and every downstream system points at the same thing.
Say (left): "This is what a configurator holds: a tree of options. An offshore substation, with transformers, GIS and topside. Choices highlighted: three 270 MVA transformers, 220 kV double busbar GIS, a two-lift topside. And rules: three 270 MVA units need a deck height of at least 9.5 metres; the heaviest lift must stay 10 % below the vessel's capacity."
Say (right): "Options, rules and constraints are nodes and edges already. The chosen variant, 3B, sits in the middle. It must satisfy requirements from the client spec and the grid code. It generates engineering objects: equipment, cables, signals. It costs something in the LCOE model. It needs work instructions for service. And it's limited by the vessel that has to lift it."
Say: "When the configurator writes its result into a shared graph, engineering, cost and service all see the same variant. No export, no re-typing, no 'which version did you get?'."
Click (blue edge): "And it works backwards too. Turbine and asset data, failure rates from operation, can feed back into the configuration rules. What you learn in year five of operation improves the next design."
Who: aimed at the configurator work towards LOD4. Ask: "Is this roughly how your rules are structured today? Where does the result go after the configurator?" Also touches engineering objects, the LCOE model and work instructions. The feedback edge is the turbine data world.
Illustrative: the options, rules and numbers are made up.
01 Why graphs are flexible
New questions, new edges. Nothing breaks.
Day 1 · asset register
has part
Turbine
Component
Day 30 · a bulletin arrives
from batch
applies to
Turbine
Component
Batch
Bulletin
Day 90 · work instructions
on
follows
changed by
Component
Task
Instruction
Bulletin
Tables: migrate first
Graph: add the edges
Point: you don't have to know every question on day 1. Each new question adds a few kinds of edge, and nothing that already works breaks.
Say (Day 1): "Day one, an asset register: turbines and their parts, with RDS-PP codes as properties. Simple."
Click (Day 30): "Day 30, an OEM service bulletin arrives. Suddenly batches matter: which bearings came from which batch, and which bulletin applies to which batch. Two new kinds of edge, in blue. The register is untouched. Everything that worked on day one still works."
Click (Day 90): "Day 90, work instructions join. Tasks are done on components, follow an instruction, and instructions get changed by bulletins. Three more kinds of edge. Day-one questions still work, and now you can ask: which instructions are affected by this bulletin?"
Click (comparison): "In a relational database, each of those steps is new tables, a schema migration, and every report that joins them needs fixing. So in practice the change gets postponed, and the knowledge goes into a spreadsheet next to the system. In a graph you add the edges. The model grows with the business, one question at a time."
Who: anyone who has built their own system and migrated its schema. Ask: "How long did the last schema change in your system take, from idea to production?"
Honest caveat if challenged: flexibility isn't free. You still need to govern the vocabulary, or it turns into a mess. That's what the recorded, reviewable index changes in part 02 are for.
01 Querying a graph
Films · DBpedia Offshore wind · Wikidata Wind park
Describe a pattern. The graph fills in the blanks.
SPARQL Data
⌘↵ runs · Esc leaves editor
Run
Point: a query is a pattern with blanks (?variables). The graph fills in every way the pattern fits. This is live: Oxigraph, a graph database compiled to WebAssembly, runs inside this slide.
Say: "Let's try it live. This box is a real graph database running inside the slide. A query is a pattern with blanks, and the graph fills in every way the pattern fits. I'll start with films, because everyone understands films: every film Mads Mikkelsen starred in, then every co-actor in those films, then how often each of them worked with him. No joins, you just walk the edges. Now your world, with real data: every offshore wind farm in Wikidata, plus your own published references. Same pattern: every wind farm Semco built a substation for, who owns them, and which of those owners have farms where you have no role yet. Then a synthetic layer of substation equipment: one transformer batch with a cluster of findings, followed straight to the real owners who need a call. Last, an illustrative wind park. Turbine C3, WTG-C03 and mølle C3 come back as one identifier. Then the bulletin: which bearings come from the batch it names? C03, and eight more in Park B. Follow those to their owners and planned tasks, and you see that only C03 has a task: Owner B hasn't been told. That's a phone call someone should make today."
Mechanics: three datasets, switch top right. Click a numbered preset, then Run (or ⌘↵). Click any value in the results to explore its neighbours. On the films set, "Run live on DBpedia" opens whatever is in the editor on the full public endpoint (dbpedia.org/sparql), which has more languages and more films than the slice in the slide. Esc hands the keyboard back to the deck; PageUp/PageDown always change slide. Prefixes are predeclared. If the slide is slow, it is loading the graph; give it a few seconds.
Films (real DBpedia data about Mads Mikkelsen). Use this to teach the idea, because everyone understands films:
1 Everything: "A graph is just a list of triples: subject, predicate, object. That's all there is."2 Mads' films: "Constants pin the pattern, variables get filled in. 'Find every ?movie that stars Mads Mikkelsen, and give me its title.'"3 Co-actors and age: two patterns sharing ?movie. Every film with Mads, every other actor in it, their birth date, computed age. The classic graph query.4 Most frequent co-stars: same pattern, counted. Reads almost like the question.5 Directors / 6 Where were they born: one hop in another direction, then two hops: film → actor → country. "No joins to write; you just walk the edges."
Offshore wind (real Wikidata data, Semco's published references, and a synthetic equipment layer). The Mads Mikkelsen queries, in Semco's world:
1 Everything: 188 offshore wind farms from Wikidata with country, sea, owners, operator, capacity, turbine model and maker. Each node links to its Wikidata item (owl:sameAs).2 Semco's farms: the "Mads' films" query. 11 farms Semco built offshore substations for, from Semco's own references: Hornsea One, Anholt, Walney, Vineyard Wind 1, Baltic Power, Baltica 2, Hai Long 2 and 3, CVOW, Formosa 4, Fengmiao 1.3 Owners and age: the co-actors query. ?role is a blank too, so substations, systems (Horns Rev 1, Kriegers Flak, Race Bank) and service (Rødsand II, Global Tech I) all match.4 Top clients: the co-stars query. Ørsted on 6, Northland Power on 3.5 Leads: the sales question. Farms owned by Semco's substation clients where Semco has no role in the data yet. Ørsted alone has 19. "That's a pipeline, from public data, in one query." Caveat: it only knows the references we added.6 Bad batch? / 7 Who to call?: synthetic, and labelled as such. Transformer batch TR-2291 (Vendor Alfa) has 10 findings across 7 farms. Follow it to the real owners: who to call. Same story as the bulletin in the wind park.Live edit, if someone wants one: farm → turbine model → maker, two hops: ?farm :turbineModel/:manufacturer/rdfs:label ?maker. Siemens Gamesa and "Siemens Gamesa Renewable Energy" come back as two makers: real data is messy, and that is the entity resolution Cue does.
If asked "is this real?": farms, owners and turbines come from Wikidata (CC0, fetched 27 October 2026; one fix: Wikidata puts Baltic Power in the North Sea). Which farms Semco worked on comes from semcomaritime.com. Substations' equipment, vendors, batches and findings are synthetic; every synthetic node has :source :Synthetic.
Wind park (illustrative, in the shape of this deck, not Semco data):
2 C03 by any name: one identifier behind "turbine C3", "WTG-C03" and "mølle C3". Labels and alternative labels.3 SB-2026-14: the bulletin question. Which bearings come from a batch named in the bulletin? Answer: C03 plus 8 bearings in Park B. Note the line a/rdfs:subClassOf* :Bearing: ask for Bearing, get pitch, main and yaw bearings. That's querying by meaning (annotated in the backup).4 Who has to act? follow them to owners and planned tasks. Only C03 has a task, so Owner B hasn't been told. "That's a phone call someone should make today."5 Alarms by class: one alarm on a pitch bearing also counts for Bearing, Rotating equipment and Component. Roll-ups by meaning, without maintaining lookup tables.6 Deviations by batch: SCADA meets production data. Batch 7731 stands out. "That's the kind of pattern you only see when the two are connected."7 Vessel knock-on: everything the heavy-lift vessel constrains, however many steps away (:constrains+), and who owns it, all the way to the LCOE model.
Timing: 5 to 8 minutes. Two film presets, then offshore wind 2, 5 and 7, then wind park 3 and 4. Add more depending on who is most engaged. Invite someone in the room to suggest an edit to a query.
If the playground fails: skip it and use the backup slide "Querying by meaning", which has the bulletin query annotated.
01 Codes and graphs
A code shows one perspective. A graph carries many.
RDS-PP · function aspect
Wind farm #DK.NSA01
WTG C03 =G014
Rotor system MDA
Pitch system, blade B
Pitch bearing
One tree, one parent per thing
Pitch bearing · B · C03
=G014 MDA… RDS-PP, function
++ hub RDS-PP, location
4471-B OEM part, batch 7731
SB-2026-14 applies to the batch
8 more in Park B same batch, other owner
WI-0231 step 7 work instruction, Mobi
WTG03-PB-B owner's CMMS tag
PO 4500-2981 warranty until 2029
Illustrative designations
Point: we don't replace RDS-PP, we carry it. A code tells you what a thing is and where it sits, from one point of view. The graph keeps the code and adds everything the thing is connected to.
Show respect first: RDS-PP, the Reference Designation System for Power Plants (VGB, based on IEC/ISO 81346), gives every object an unambiguous hierarchical code. Semco works with it daily, and many owners ask for it. It's a real achievement. Detail in the backup slide if asked.
Say (left): "Here's the function aspect for one pitch bearing: the wind farm, turbine G014, the rotor system MDA, the pitch system for blade B, and the bearing. It's a tree: every thing has exactly one parent, seen from one point of view. Function is one tree, product another, location a third."
Say (right): "Now the same bearing in a graph. The RDS-PP function code is one edge. The location code, another. And then everything the tree can't hold: the OEM part number and batch 7731. The bulletin that applies to that batch. The eight other bearings from the same batch, sitting in Park B, owned by someone else. The work instruction step in Mobi that touches it. The owner's own CMMS tag for the same physical bearing. The purchase order, with warranty until 2029."
Say: "The questions that matter cross trees. 'This bulletin: which of my turbines, and which of my customers' turbines?' is not a question any single code can answer. The graph links the owner's, the OEM's and your own codes for the same bearing."
Who: turbine data (coded this way) and Mobi work instructions (which reference these codes).
Bridge: "So how do we build a graph like this from your documents and systems, without asking you to type it in? That's the Cue Index."
02
The Cue Index
From pages and records to one graph you can ask.
Point: about 20 minutes. How Cue builds the graph from documents and systems, how people and agents ask it, and how every change is kept on record.
Say: "So far: what a graph is and why it suits your data. Now: how we build one from your actual documents and systems, without anyone typing it in."
02 From documents to answers
Read. Recognise. Connect.
1
Read every page
Inspection of TURBINE WTG C03DATE 14 Mar 2026PERSON J. PedersenLOCATION segment 4DOCUMENT PR-118 rev 7
2
Recognise the things
Turbine · 214 mentions
Procedure · 8 revisions
Technician · 61 tasks
Location on bearing
3
Connect into a graph
WTG C03 PR-118 J. Pedersen Segment 4 Inspection
Stop searching. Start asking.
Point: three steps underneath every answer: read, recognise, connect. Reading isn't new. The hard parts are step 2, deciding that three spellings are one turbine, and step 3, keeping every fact traceable to its source.
Say (1, Read): "Cue reads every page: PDFs, scans, spreadsheets, drawings, e-mail, in any language. Here's one sentence from an inspection report. Cue marks what it finds: a turbine, a date, a person, a location, a document reference."
Click (2, Recognise): "Then it recognises them as things it already knows. WTG C03 isn't just a string; it's the turbine that has been mentioned 214 times across the archive. PR-118 is a procedure with 8 revisions. J. Pedersen is a technician with 61 tasks. And 'C03', 'WTG-C03' and 'turbine C3' are one thing, not three."
Click (3, Connect): "Then it connects them into the graph. The turbine, the procedure, the technician, the location, the inspection. Every fact keeps a link to the page it came from, so you can always click through and check."
Click: "Which means you can stop searching for documents and start asking questions."
If asked how: layout-aware document parsing and OCR, LLM-based extraction guided by the vocabulary (next slide), then entity resolution (the slide after). Everything goes through an event log, so the index can always be rebuilt.
Bridge: "Step 2 only works if Cue knows what to look for. That's the vocabulary."
02 Tell Cue what matters
You don't start from scratch
Category Known values
Organisation Semco Maritime Siemens Energy Ørsted …
Equipment Power transformer GIS bay Shunt reactor …
Turbine WTG C03 WTG B05 …
Work instruction WI-0231 PR-118 …
Document type Datasheet GA drawing ITP Single-line diagram
Discipline E I M S P
Your vocabulary, in three layers
1 Standard vocabulary day one
2 Your codes RDS-PP · numbering · tag lists
3 Grows as you work from files and questions
Illustrative values
Point: the vocabulary is what Cue looks for when it reads. It's the ontology from part 01, made practical. You don't start from a blank page.
Say (table): "This is what a vocabulary looks like in Cue: categories, and known values for each. Organisations: Semco, Siemens Energy, Ørsted. Equipment: power transformer, GIS bay, shunt reactor. Turbines, work instructions, document types, disciplines."
Say (1): "It starts from a standard vocabulary: organisations, people, dates, documents, equipment. That works on day one, on any document."
Click (2): "Then your own codes: RDS-PP, your document numbering, your tag lists. Your numbering becomes vocabulary, so 'all electrical datasheets from vendors on OSS2' becomes a question, not a filter someone has to build."
If asked how: the backup slide 'Your numbering becomes vocabulary' shows it.
Click (3): "And it grows as you work. From a few typical files we propose a tailored vocabulary. And from the questions people ask: when someone asks something the vocabulary can't express, Cue proposes the missing category. More on that in a few slides: nothing changes silently."
Who: engineering and the configurator team will recognise their own classification schemes. Ask: "Which code systems do you live with every day?" Write them down; they're good input for the workshop.
Illustrative: the values are examples.
02 Connect
From mentions to one thing
Selected option:
MPT-1, 270 MVA
Tag:
TR-01
Unit:
Main power transformer no. 1
§ 7.3.2:
Transformer T1
Step 3:
T1 cooling fans
one thing
Point: this is the step that makes the graph useful. Five sources, five names, one transformer.
Say (left to right): "The configurator export says MPT-1, 270 MVA. The single-line diagram tags it TR-01. The vendor datasheet calls it Main power transformer no. 1. The client specification, section 7.3.2, says Transformer T1. And the work instruction, step 3, talks about the T1 cooling fans."
Ask the room: "How many of you would know instantly that these are the same transformer? Right: you would. A new colleague wouldn't. And a search engine certainly wouldn't."
Click (one thing): "Cue resolves them to one entity and keeps every mention linked to its page. Ask about T1 once, and you get the configurator, the drawing, the vendor, the spec and the service task."
For the curious: this is entity resolution. The backup slide "A ladder of checks" shows how Cue decides: tidy up, find candidates, weigh the evidence, and only for the unclear cases, an AI judge that sees the graph context. Its example: Siemens Energy vs. Siemens Gamesa, same brand, different companies, kept apart. Jump there if asked.
If asked "what if it merges wrongly?": every merge is recorded with its evidence and can be undone; see the "Recorded, reviewable, reversible" slide in a moment.
02 The Cue Index
One index, three kinds of question
What is connected to what?
the graph: documents, pages, things, relations
What is this about?
search by meaning, over summaries
Where is this word?
classic full-text search
A complete, ordered history
1041 document added · OSS2-SEM-E-DS-0412.pdf
1042 pages read · 6
1043 mentions extracted · 23
1044 connected · Transformer T1, Siemens Energy
Can always be rebuilt. New documents extend it.
Point: one index, three ways to ask it. Agents use all three, and all three are built from one ordered history.
Click (top layer): "The graph answers 'what is connected to what?': documents, pages, things and relations. Which bearings are in this batch, who owns those turbines."
Click (middle): "Search by meaning answers 'what is this about?'. Ask for 'grease leakage' and find the report that says 'lubricant escaping at the seal'. That's a vector index over summaries."
Click (bottom): "Classic full-text search answers 'where is this exact word?'. When you need the exact tag, TR-01, nothing beats it."
Click (history): "And underneath, a complete, ordered history. Document added, pages read, mentions extracted, connected. Every step is an event. The index can always be rebuilt from it, and new documents extend it."
Why it matters (bridge to part 03): you can see exactly when and how anything entered the index. That's the audit trail part 03 covers.
Technical detail: a knowledge graph (RDF, queried with SPARQL), a vector index and a full-text index, all projections of one event log (event sourcing).
02 Agents query by meaning too
An agent reads your vocabulary, then asks the graph
Which turbines have bearings from the batch in SB-2026-14, and were any of them greased the old way since March?
index_schemaRead the vocabulary: Bearing, Batch, Bulletin, Task, Procedure
index_searchFind SB-2026-14 and the batch it names
index_traverseFollow applies to → from batch → part of → inspected
Answer
9 turbines in 2 parks carry bearings from batch 7731. 3 were greased under rev 7 since March: B05, C03, E02 .
Suggested next step: brief the C03 crew before Tuesday.
Illustrative · tool names from the Cue MCP server
Point: the same bulletin question as in the SPARQL playground, now asked in plain language by someone who has never heard of SPARQL. The agent never needs your table names: it reads what your things mean.
Say (the question): read it out. "A service planner asks this in Claude or Copilot: which turbines have bearings from the batch in SB-2026-14, and were any of them greased the old way since March?"
Click through the four steps:
index_schema: "First the agent reads the vocabulary. Bearing, Batch, Bulletin, Task, Procedure, and how they relate. Like a new colleague reading the org chart before asking questions."index_search: "It finds SB-2026-14 and the batch it names."index_traverse: "It follows the edges: applies to, from batch, part of, inspected. The same path we walked by hand in part 01.""It keeps the tasks done under the old procedure, rev 7 or earlier."
Click (answer): "Nine turbines in two parks carry bearings from batch 7731. Three were greased the old way since March: B05, C03, E02. Each claim links to its source: the bulletin and three work orders. And a suggested next step: brief the C03 crew before Tuesday." (That's where the podcast in the inspiration part comes from.)
Say: "Because the graph has meaning attached, the agent doesn't have to guess column names, and every step leaves a trail you can inspect."
Technical detail: the tool names are real, from the Cue MCP server. Works from Claude, Copilot or any MCP client, and from the Cue SDK for your own apps.
Illustrative: the data and answer are made up.
02 Architecture
Data at the centre
People & agents Product engineers Data analysts Service technicians IT Customers
Interfacesgenerated, cheap, many Configurator views Work instructions LCOE studies Fleet dashboards Assistants Reports
MCP · SDK · SPARQL · REST
Cue Index Semantic model Knowledge graph Documents Connectors and document reading
Sourcesstay where they are Configurator Engineering tools Mobi SCADA & turbine data ERP Document control Cost models File shares
Point: data at the centre. Nothing gets ripped out: sources stay where they are, Cue sits in the middle as the shared model, interfaces on top are cheap and many.
Say (bottom up):
"At the bottom, your sources: configurator, engineering tools, Mobi, SCADA, ERP, document control, cost models, file shares. They stay. Cue connects to them and reads documents."
"In the middle, the Cue Index: the semantic model, the knowledge graph, the documents. And three properties built in: permissions, provenance, history."
"On top, the interfaces. Dashed, because they're generated, cheap and many: configurator views, work instructions, LCOE studies, fleet dashboards, assistants, reports. Remember the tech intro: the app isn't the hard part any more."
"And at the very top, the people and the AI agents who use them."
For IT: "This is an integration pattern: one shared model instead of point-to-point links between every pair of systems. With n systems, point-to-point needs up to n×(n−1)/2 links; here each system connects once."
Bridge: "Permissions, provenance and history in the middle layer are what part 03 covers. One of them I want to show you first: what happens when the vocabulary changes."
02 Every change on record
Recorded, reviewable, reversible
Index change 7f3c2a9e applied
WHAT +1 category Torque specification (provisional) · +14 mentions · +9 relations
WHY A service planner asked which work instructions use a torque value that a newer bulletin changed. The vocabulary could not express it.
EVIDENCE PR-118 rev 8 · §4.6 SB-2026-14 WI-0231 · step 7
WHO Service planner · via their AI assistant · 21 Oct 2026, 10:14
To review
Torque specification provisional
Merge into…
Any change can be rolled back
Illustrative
Point: the vocabulary grows from the questions people ask, but never silently. Every change is recorded, reviewable and reversible.
Say (index change): "Here's what a recorded change to the index looks like. A service planner asked which work instructions use a torque value that a newer bulletin changed. The vocabulary couldn't express 'torque specification', so their AI assistant proposed a new category."
What: one new category, Torque specification, provisional; 14 mentions; 9 relations.Why: the question that couldn't be answered.Evidence: the procedure clause, the bulletin, the work instruction step.Who: the service planner, via their assistant, with a timestamp.
Click (review): "A provisional category is visible and searchable for everyone straight away, but Cue only uses it for extraction once a person has promoted it. You can promote it, merge it into an existing category, or reject it."
Click (roll back): "And any change can be rolled back, as one new entry that undoes it. The history stays complete: you can always see what was there, and when."
For IT: this is the governance story. Agents may propose; people decide; everything is on record.
Bridge: "Which brings us to trust, security and compliance." Hand over.
03
Security &
Where your data lives, who sees what, and how it holds up to an audit.
03 Trust
Built to be trusted
Every answer has a source
Access per project, checked on every request
Full history
Cue doesn't invent facts. No source, no fact.
Bridge from part 02: the three properties of the index.
Say: "Three properties hold it all together."
Every answer has a source: a link to the page, the cell or the record it came from. Click it, check it.Access per project, checked on every request: people only see the projects they are members of, and the gateway checks every request. Note: access is per project, not per document. You decide what goes into each project.Full history: who added what, when and why, and every change can be undone.
Say (punchline): "Cue doesn't invent facts. No source, no fact."
If challenged: this means nothing enters the index without a source to check, not that a reading can never be wrong. That is why the source is one click away and every change can be rolled back.
03 Hosting
Where your data lives
In Europe, on Google Cloud
Apps, files and the graph run in Zurich (europe-west6 ) AI models run on Google Vertex AI in EU regions
Every project kept apart
Each project has its own files and its own graph, vector and text index The gateway checks each request against the project and its members
Encrypted and backed up
Google Cloud encryption at rest, HTTPS for every request Project indexes backed up to storage every 6 hours
Deleted when you ask
Delete in the app; it can be restored if it was a mistake Permanent wipe on request: graph, indexes, backups, files and logs Nothing expires on its own: your data stays until you delete it
On-premises is on the way. Every backend is one setting, and storage and messaging already run on open alternatives (S3, NATS).
Default deployment: Google Cloud, Zurich region for compute, storage and the graph server. Language models via Vertex AI in EU regions (europe-west1, the EU multi-region, europe-west4 for Mistral). Separation is logical: shared infrastructure, but every project has its own storage prefix and its own QLever, LanceDB and Tantivy index, and the Kong gateway rejects any request for a project the user isn't a member of. Data is kept until the project is deleted; there is no automatic expiry. Deleting in the app is a soft delete (a Qaecy superadmin can restore it); the permanent wipe, including index backups, is done by Qaecy on request. Backends are a config value, which is how on-prem works: MinIO and NATS are done, Postgres and own identity provider are in progress. No date for on-prem yet.
03 Access
Who sees what
Sign-in and roles
Sign in with Microsoft, Google or email and password Roles per project: admin , syncer (adds data), member (reads) Access is granted per project, and every request is checked
The gateway decides
Every request passes one gateway that checks the sign-in and the user's role in the project The services behind it trust only the gateway, never what an app says about itself No direct access to files or databases from outside
AI agents over MCP and the API
An agent signs in as its user (OAuth) or with a personal API key that expires It gets exactly its user's roles, checked on every tool call Every change it makes to the index is recorded as made by an agent, for its user
Credentials for private registries
Encrypted with AES-256-GCM, key held in Secret Manager Write-only: no route hands them back, and they never pass through a chat Only admins can set them
For IT. Authentication is Firebase/Google Identity with Microsoft, Google and password providers. Authorization is per project with three roles; higher roles include lower ones. The Kong gateway loads the project, checks the roles and overwrites the identity headers, so upstream services only trust what the gateway says. Sign-in tokens are short-lived (1 hour) and renewed with a refresh token; the gateway verifies the token on every request, then passes the user id, roles and project on to the services. MCP: same roles as the human user, membership re-checked per call. Private registries are the semi-public sources (registers) that need a key or login. Limitations today: access is per project, not per document, and SSO is not yet restricted to a customer's own Entra tenant.
03 AI and your data
AI, under control
Models, and where they run
Gemini by default; Claude and Mistral are options too All through Google Vertex AI in EU regions, under Qaecy's own Google Cloud project Embeddings in Zurich
Facts keep their source
Every extracted fact points to the document, page or table it came from
Every change on record
Every change to the index records what changed, why , on which evidence , and who made it Who includes what kind of actor: a person in a Cue app, or an AI agent over MCP working for its user Cue determines this itself at the gateway, so an agent cannot pass as a person History is append-only; any change can be rolled back as a new entry What an auditor can see: who changed what, when, why, and from which source
Model registry: Gemini 2.5 Pro/Flash/Flash-Lite are the defaults (europe-west1); Claude via Vertex in the EU multi-region with no Anthropic key; Mistral in europe-west4; embeddings europe-west6. Same record as the earlier "Recorded, reviewable, reversible" slide. Under the hood every write is an append-only commit with author, timestamp and checksums; whether it came from a Cue app or from an agent over MCP is set by the gateway from the sign-in, not reported by the client. Leave time for questions from IT.
Takeaways
Three things to remember
1 A graph holds the connections .
2 Every fact has a source .
3 Your data stays yours .
Point: recap of the educational block in three sentences. Say them in full.
Say: "Three things to take with you."
Click through the three:
1. "A graph stores the connections your systems leave to people: configurator, engineering, service, operation and cost, on one model."2. "The Cue Index reads, recognises and connects. Every fact has a source, and every change is on record."3. "Trust is built in: access is checked on every request, every change is on record, and your data stays yours."
Then: open for questions for two or three minutes before the agenda and the inspiration part.
Bridge: "Questions so far? Then some inspiration."
Today
Agenda
Together
QAECY
Inspire
QAECY
Tech intro : from chatbots to agents, and the context layer
Educate
Semco
Listen
QAECY
Educate
QAECY
Inspiration : service briefings, and logistics with Loglay
Inspire Next
Together
Work
Together
Inspiration
What you can buildon one index
Briefing service crews, and planning site logistics with Loglay.
Point: two examples of what you can build once the index exists. Chosen because they sit at both ends of Semco's business: O&M crews in the field, and the yard and site where substations are built.
Say: "Enough theory. Two examples, both built on the same index, to give you ideas for the workshop."
Inspiration · Service crews
The procedure changed.Did the technician?
PR-118 Pitch bearing inspection rev 7 → rev 8
4.2 Clean the seal area with a lint-free cloth.
4.3 Apply grease until fresh grease is visible at the seal lip.
4.3 Apply 380 g grease per nipple, max. 2 strokes per 10 s. Do not over-grease: seal lip damage (SB-2026-14).
4.5 Photograph each seal segment and upload to the work order.
4.6 Check pitch bearing bolts: 10 % sample, 2,400 Nm.
4.6 Check pitch bearing bolts: 100 %, 2,550 Nm, cross pattern.
AK
Anna K. Service technician
Last did this task March 2025 · rev 6
Changes since 5, across rev 7 and 8
Briefing
Illustrative
Point: this is the challenge Semco raised with us: service personnel aren't always up to date on the latest requirements for a task. The information exists. The problem is format and timing.
Say (diff): "PR-118, pitch bearing inspection, from revision 7 to 8. Look at what changed. Greasing used to be 'until fresh grease is visible'; now it's 380 grams per nipple, at most two strokes per ten seconds, because over-greasing damages the seal lip: that's the OEM bulletin. A new step: photograph every seal segment. And the bolt check went from a 10 % sample at 2,400 Nm to 100 % at 2,550 Nm in a cross pattern. Those are not cosmetic changes."
Say (Anna): "Meet Anna. She last did this task in March 2025, under revision 6. Five changes since, across two revisions. Briefing: not done."
Say: "Requirements change faster than people can read them. The information is in revision 8 of a PDF. But nobody reads a 40-page procedure diff on the quayside at 05:30. The gap between the document and the person is where incidents and rework come from."
Who: the Mobi team. Ask: "How do technicians learn about a changed procedure today?"
Illustrative: procedure, values and person are made up.
Inspiration · From requirements to formats people use
Cue knows what changed, for whom, for which task
what changed for whom which task
Podcast
Video
AR guidance
Sign-off
Point: the key move is not generating content. It's that Cue knows what changed between revisions, for whom, and for which task. From there, generating a format people actually use is the easy part.
Say (left): "The inputs are all things Semco already has: procedures and their revisions, OEM service bulletins, HSE alerts and regulations, the turbine's history, lessons learned, and training records."
Say (middle): "Cue compares revisions, matches the changes to the task, the turbine and the person, and writes the briefing from those sources. Not from the internet; from your documents, with every sentence traceable to a clause."
Click through the four formats:
Podcast: an eight-minute briefing for the CTV transit. Next slide.Video: step-by-step instructions, in the technician's own language. Shown after the podcast.AR guidance: at the component, hands-free. Shown after the video.Sign-off: three questions, acknowledged, traceable. Evidence for the owner and the auditor that the briefing happened.
Mobi: these are formats Mobi could deliver. The index supplies the "what changed, for whom"; Mobi stays the place technicians work.
Inspiration · Podcast briefing
Briefed on the boat, not on paper
Morning briefing
02:41 / 08:12 EN · DA · PL
PR-118 rev 8 SB-2026-14 C03 history
Host Morning. You're heading to C03 today: pitch bearing inspection on blade B. Two things have changed since you last did this task.
Expert First, greasing. It's no longer "until you see fresh grease". It's 380 grams per nipple, at most two strokes every ten seconds. The OEM found seal-lip damage from over-greasing; that's service bulletin 14.
Host Second: C03 had grease leakage at segment 4 in March. Photograph every segment this time; the photos go straight into the work order.
Expert Seal kits are already on the vessel. Weather window closes at three. Stay safe out there.
Illustrative script, generated from the sources shown
Point: format matters. Technicians spend an hour or more on a crew transfer vessel each way. A two-voice briefing, specific to today's turbine and today's task, in their own language, is something people actually listen to.
Say: "Morning briefing for WTG C03, Tuesday. Eight minutes, in English, Danish or Polish. Here's how it starts." Read the script ideally in two voices (a colleague reads the Expert lines).
Say (Host): "Morning. You're heading to C03 today: pitch bearing inspection on blade B. Two things have changed since you last did this task."
Click through the script:
Expert: "First, greasing. It's no longer until you see fresh grease. It's 380 grams per nipple, at most two strokes every ten seconds. The OEM found seal-lip damage from over-greasing; that's service bulletin 14."
Host: "Second: C03 had grease leakage at segment 4 in March. Photograph every segment this time; the photos go straight into the work order."
Expert: "Seal kits are already on the vessel. Weather window closes at three. Stay safe out there."
Say: "Every sentence traces back to a source: the procedure revision, the bulletin, the turbine's history. The chips under the player are those sources."
If asked "is this real?": the script is illustrative, generated from the sources shown. Generating the audio itself is commodity text-to-speech today; the hard part is knowing what to say to whom.
Inspiration · Video instructions
Generated from the procedure, rendered from the model
1 · Lock the pitch system Rotor lock engaged, pitch in maintenance mode. PR-118 §3.1
2 · Clean the seal area Lint-free cloth, all segments. PR-118 §4.2
380 g 00:51 New in rev 8
3 · Grease: 380 g per nipple Max. 2 strokes per 10 s. Don't over-grease. PR-118 §4.3 · SB-2026-14
01:20 New in rev 8
4 · Photograph each segment Uploads straight to WO-88140. PR-118 §4.5
English Dansk Polski Deutsch
Point: same source, different format. Short clips per step, changes flagged, each frame citing the paragraph it comes from.
Say: "Same procedure, now as video. One short clip per step, rendered from the model, in the technician's own language. Steps three and four are new in rev 8, so they're flagged, and every frame cites the paragraph it comes from."
Say: "When rev 9 arrives, the clips are regenerated. No one has to re-shoot a training video."
Inspiration · AR in the field
Hands-free, at the bolt, always the current revision
Step-by-step guidance anchored to the component
Changes since your last visit flagged in view
Torque values logged by the tool, straight into the work order
WO-88231 WTG D04 · TOWER T2/T3 REC ●
Point: a tower flange bolt check inside the tower base. The goggles show the step, the torque, which bolt is next in the cross pattern, and what changed since the technician last did the task.
Say: "Now at the component. Hands-free, anchored to the flange, always the current revision. And the torque values come straight from the tool into the work order."
Click: "This is the technician's view through the goggles. Step six of nine, 2,550 newton metres, the next bolt in the cross pattern lit up. Top right: the torque changed since rev 3, the last time this technician did the task."
Inspiration · Closing the loop
Field data flows back
Point: it's a loop, not a pipeline. Every executed instruction produces data; connected to the turbine and the component in the graph, it becomes fleet insight, which updates the instructions.
Say (walk the cycle): "The technician does the task, guided by the briefing. Photos, torque values and findings go back into the Cue Index, linked to the turbine, the component and the procedure step. Across the fleet, patterns surface: this batch leaks more, that step is often skipped. The instruction gets better, and the next briefing is sharper."
Three things it gives you: work instructions that improve, turbine data with context, and evidence for the owner that the work was done to the latest revision.
Who: this is where Mobi and turbine data meet. Ask: "Where does field feedback go today?"
Inspiration · Logistics, with Loglay
Is the plan buildable ?
Weekly installed quantity · one trade % of the trade's total, per week
0 %
10 %
20 %
Week 1: 1 % of the trade's total W1
Week 2: 1 % of the trade's total Week 3: 2 % of the trade's total Week 4: 2 % of the trade's total Week 5: 3 % of the trade's total W5
Week 6: 2 % of the trade's total Week 7: 3 % of the trade's total Week 8: 4 % of the trade's total Week 9: 18 % of the trade's total W9
Week 10: 22 % of the trade's total Week 11: 21 % of the trade's total Week 12: 17 % of the trade's total Week 13: 2 % of the trade's total W13
Week 14: 1 % of the trade's total Week 15: 1 % of the trade's total Week 16: 0 % of the trade's total Week 17: 0 % of the trade's total W17
Week 18: 0 % of the trade's total Week 19: 0 % of the trade's total Week 20: 0 % of the trade's total 78 % in 4 weeks
~80 % in four weeks one trade's work, compressed into its busiest weeks
20+ activities, up to 8 trades in one zone, in the same weeks
30+ locations in one week for a single trade
Trucks, pallets, storage, waste per trade and location, from the classified components
Illustrative, after an anonymised fit-out programme analysed by Loglay's BIM2LOG Hermes
Point: a plan can look fine as a Gantt chart and still be unbuildable. Loglay makes that visible from the model and the programme.
Who Loglay are: a partner of ours. Their tool, BIM2LOG Hermes, reads IFC models and the construction programme, classifies every component and activity by trade, standardises storeys and zones across sources, and computes workload, coordination and logistics indicators.
Say (chart): "This is one trade's installed quantity per week, as a share of its total. Computed from the model's quantities and the programme's activities, spread over working days and summed per week. 78 % of the trade's whole scope falls in four weeks, 9 to 12. Everything else is a trickle."
Say (cards): "And it's not alone: more than 20 activities from up to 8 trades in one zone in the same weeks. One trade working in more than 30 locations in a single week. And from the classified components: trucks, pallets, storage and waste per trade and location."
Ask: "Does that look buildable?" Let the room answer.
For Semco: think topside fit-out at the yard, where E&I, HVAC and piping crowd the same rooms in the same weeks.
Illustrative: after an anonymised fit-out programme from Loglay's own write-up, not a Semco project.
Inspiration · Logistics, with Loglay
See the topside as it really is
Progress per zone from the yard, compared with the plan for that zone this week.
Two zones behind. One waits for piping, one for a late PO. Both reasons come from other systems.
Illustrative
Point: from the plan to reality. Progress per zone from the yard, compared with the plan for that zone this week.
Say: "Now bring it to your yard. This is a topside, zone by zone, coloured by progress against this week's plan. 61 % complete, 68 % planned."
Click: "Two zones are behind. L2-B is waiting for piping, L3-A for a late purchase order. Neither reason lives in the yard's progress report: one comes from the schedule, the other from the ERP."
Where the data comes from: whatever the yard already reports (spreadsheets, photos, punch lists), connected to zones in the model.
Inspiration · Logistics, with Loglay
Plan vs. reality, per location
Each line is a trade moving through the topside. Where two lines meet, two crews want the same zone at the same time.
Illustrative
Point: location-based scheduling. Instead of activities in a Gantt chart, each trade is a line through locations, and the slope is its production rate. That makes clashes visible a week before they happen.
Say: "Each line is a trade moving up through the topside: steel, piping, E and I, HVAC, commissioning. Dashed is the plan."
Click: "Solid is what the yard actually reports. Piping is running slow: its line is flatter than planned."
Click: "And this is the projection. E and I is about to run into piping that isn't finished, in L2-B, next week. Two crews, one zone: idle time and rework, unless E and I is resequenced now."
Say: "A Gantt chart wouldn't show this. A connected model shows it a week early."
Inspiration · Logistics, with Loglay
Readiness needs the documents too
Loglay · BIM2LOG Hermes models & programmes
Classification by trade Standard storeys & zones Workload & concurrency Transport & logistics Constructability report
Cue Index everything else
Specifications Drawings & revisions RFIs & submissions Meeting minutes Inspection records Procurement Site reports
Finding · L2, Zone B
Ceiling closure: electrical inspected, no ventilation inspection found.
Method statement ITP Inspection log
Illustrative finding · proposed partnership
Point: readiness needs the documents too, not just the model and the programme. That's the partnership: Loglay does models and programmes, Cue does everything else, and they talk over MCP.
Say (top box): "Loglay already does models and programmes well: classification by trade, standard storeys and zones, workload and concurrency, transport and logistics, a constructability report."
Click (Cue box): "But whether a work package can actually start depends on documents: specifications, drawings and revisions, RFIs and submissions, meeting minutes, inspection records, procurement, site reports. Loglay's own roadmap is to extend to that wider document set, 'with the connected project context carrying the links between documents'. That's the Cue Index. Hermes asks Cue over MCP and writes its findings back, with source and confidence, so they show up next to everything else."
The questions it answers: can this work package start as planned? Do the trades fit the planned sequence? What else does this change affect? Which open RFIs matter for the next weeks?
Click (finding): "Here's what a finding looks like. Level 2, zone B, ceiling closure. The method statement requires inspection of concealed services before the ceiling is closed. Electrical has been inspected. No ventilation inspection record found. So: confirm before releasing for closure."
Important nuance, say it: "A missing record doesn't prove the check wasn't done. It names the evidence a reliable decision needs."
Illustrative: proposed partnership; the finding is an example.
Inspiration · One index
One index. Many apps, many partners.
MCP Connectors SDK SPARQL
Cuethe common context
Point: one index, many apps, many partners. Briefings, work instructions and logistics all need the same things: the turbine, the component, the zone, the latest revision. Cue holds them once.
Say: "One index, and on top of it, many apps and many partners."
Click through the apps:
"Podcast briefings." "Work instructions in Mobi." "Logistics with Loglay." "Fleet analytics." "Constructability." "The LCOE model." "The configurator." "Video and AR."
Say: "Each one is an app or a partner tool on the same index."
Say: "Partner tools connect to the index instead of to each other, and write their results back with their sources. Where a source or a partner isn't connected yet, we build the connector."
For Mobi: "Mobi reading from a shared index is also what lets it run on another customer's fleet. If Mobi talks to Semco's systems directly, every new customer is an integration project. If it talks to an index, the new customer just needs an index." That's the step from in-house tool to product.
Bridge: "That's the inspiration. Now let's work on yours: the ship framework."
Today
Agenda
Together
QAECY
Inspire
QAECY
Tech intro : from chatbots to agents, and the context layer
Educate
Semco
Listen
QAECY
Educate
QAECY
Inspiration : service briefings, and logistics with Loglay
Inspire
Together
Work Next
Together
Up next: Ship framework workshop.
Together
Ship frameworkworkshop
Placeholder: switch to the workshop material.
Today
Agenda
Together
QAECY
Inspire
QAECY
Tech intro : from chatbots to agents, and the context layer
Educate
Semco
Listen
QAECY
Educate
QAECY
Inspiration : service briefings, and logistics with Loglay
Inspire
Together
Work
Together
Next
Thank you
Philipp Dohmen · Manos Argyris · Mads Holten Rasmussen
Backup
More detail, if asked
Slides kept out of the main flow: the semantic model, following edges, querying by meaning, RDS-PP, numbering schemes, how Cue decides, and sources.
Not counted in the slide numbers. Jump here for questions.
01 Semantic model
Your world, described
Facts the model holds
OSS-2 configured as Variant 3B
Variant 3B specifies Transformer T1
T1 must satisfy REQ-0412
T1 delivered under PO 4500-1832
T1 cooling check follows WI-0231 rev 4
Variant 3B costs 41.8 €/MWh
Configurator, engineering, purchasing, service and cost: one graph, one identifier per thing.
This is what we mean by a semantic model. Not a database schema an IT vendor gave you, but the things Semco talks about and how they relate, in Semco's words. One transformer connects a variant (configurator), a requirement (engineering), a PO (ERP), a work instruction (Mobi) and a cost (LCOE).
01 Following edges
One outside fact, a chain of decisions
Follow a single boundary condition into the design.
Heavy-lift vessel Crane capacity and availability in the installation window
Max lift weight Topside incl. rigging, contingency and weight growth
Transformers & module split Two large units or three smaller ones? One lift or two?
Layout & deck heights Bays, fire walls, CoG envelope
Jacket & piles Loads checked against the seabed data
Cost & LCOE Capex, installation cost, lifetime
In documents The vessel slips six weeks. Someone has to remember which studies, drawings, rules and cost models depend on it, and who owns them.
In a graph The constraint is linked to everything it limits. Change it, follow the edges, and the whole chain lights up, with the documents and owners attached.
Traversal: the thing graphs do that tables struggle with. A boundary condition is just another node, with edges to the decisions it constrains. The last link is the LCOE model: the LCOE numbers move when the vessel moves.
01 Querying by meaning
Ask for what things are , not what they're called
The ontology says
Component
Rotating equipment
Bearing
Pitch bearing Main bearing Yaw bearing Gearbox Generator
# Which bearings come from a batch named in SB-2026-14?
SELECT ?bearing ?turbine WHERE {
:SB-2026-14 :appliesTo ?batch .
?bearing a/rdfs:subClassOf* :Bearing ;
:fromBatch ?batch ;
:partOf ?turbine .
}
Asking for Bearing also finds pitch, main and yaw bearings, because the ontology says they are bearings.
Ask for Rotating equipment and gearboxes and generators come along. Nobody had to tag them twice.
"C03", "WTG-C03" and "turbine C3", in English, Danish or OEM speak, point to one identifier.
SPARQL is the W3C query language for graphs. Don't read the query out; point at the shape: it reads almost like the question. The key line is "a/rdfs:subClassOf*": follow the class hierarchy, so the query works on meaning, not on exact labels. For turbine data: this is how you'd slice turbine data by component class without maintaining lookup tables.
01 RDS-PP
A code for every thing
The Reference Designation System for Power Plants gives each object in a wind farm or substation an unambiguous, hierarchical code.
#DK.NSA01Conjoint
=G001Main system
MDA10System
BT002Basic function
= Function What it does. The backbone of the designation.
− Product What realises it: the transmitter -BT001 and its cable -WG001.
+ Location Where it sits: in a cabinet (+) or in a space such as the nacelle (++).
Valuable: one code across owner, OEM and service company, and asked for by many owners.
VGB / vgbe RDS-PP for wind; example after soedera.eu
Show respect for RDS-PP: it's a real achievement and Semco works with it daily. Then the next slide: what it can't do on its own.
02 Your codes
Your numbering becomes vocabulary
OSS2 - SEM - E - DS - 0412
Project OSS2 Offshore substation 2
Originator SEM Semco Maritime SEM · CLI · VND
Discipline E Electrical E · I · M · S · P
Document type DS Datasheet DS · GA · SLD · ITP
Number 0412 running number
Preview nothing applied yet
OSS2-SEM-E-DS-0412.pdf file name Electrical Datasheet Semco
OSS2-VND-E-SLD-0007.dwg file name Electrical Single-line diagram Vendor
Scan_0419.pdf in the title block Mechanical GA drawing
Notes_site_visit.docx no code found
Illustrative numbering scheme
Every company has a numbering scheme; most systems only use it as a string. Cue turns each segment into vocabulary, so "all electrical datasheets from vendors on OSS2" becomes a question, not a filter someone has to build. Same idea for RDS-PP and tag lists. Nothing is applied until someone has seen the preview.
02 Connect · How Cue decides
A ladder of checks
1 Tidy up normalise spelling, case, dates
2 Find candidates by spelling · meaning · keyword
3 Weigh the evidence names · meaning · neighbours · properties
4 AI judge only the unclear cases
simplest, cheapest most careful
3 · Weigh the evidence
Siemens Energy vs Siemens Gamesa
Names similar
Meaning partly: both energy suppliers
Neighbours transformers, GIS · vs · turbines, blades
Company no. different registrations differs
4 · AI judge, with context
"A transformer supplier is not the turbine OEM that shares its brand."
False merge avoided
For the curious: blocking, similarity over text and embeddings, graph context, then LLM adjudication
Most merges are settled cheaply in steps 1 and 2. Only the unclear cases go to the AI judge, and it sees the graph context, not just the two names. The example is close to home: a transformer supplier and a turbine OEM share a brand but are different companies with different neighbours in the graph. Technical detail: blocking, text and embedding similarity, neighbourhood features, LLM adjudication.
02 Sources
Sources beyond your own documents
EU and national regulation Network codes Permits and consent decisions Official gazettes
Semi-public behind a login
OEM service portals Service bulletins Client data rooms
Your own in your closed environment
Purchased standards Client specifications Semco procedures Work instructions
What applies follows from where the project lies : a Danish site brings Danish rules, a German site German ones. Checked before a source goes live: draft, test, publish.
Registers are kept as searchable records beside the project's own documents, and kept fresh. Semi-public sources keep their credentials sealed. Your own purchased standards and procedures stay in your closed environment. Hand-over to part 03: who can see what is a big part of part 03.
×
by