KBOps

The goals and the two-day agenda for the Glendale workshop in my hand, with the sticky-note legend beside them. The sequence is deliberate: users before journey, journey before MVP, MVP before assignments. The third goal, seeding material for the functional teams, is what made it a working session rather than an offsite. Beside the board, the room at work on the first and second days: colleagues writing stickies at the wall, then the group reading the journey back together, with the tripod and a laptop on a video call in shot.

Data scientists, designers, product team members, and company leadership gathered in Glendale for a multi-day workshop to outline an ambitious program around knowledge management. The product goal was to operationalize Beyond.ai's advanced AI technologies with industrial domain expertise. I orchestrated this session with an agenda of co-creation activities to extract differing views and bring them into alignment across a desired customer journey. We surfaced key engagement points with users of the system and built out a multi-stage research and development roadmap.

The Advanced Alerting concept in one picture, drawn on the first day: a real-time data stream and an expert's rules go into a knowledge base that holds when, what value and what to do, and come out as a notification or an action.

Our activities included persona definitions and situating those personas into our desired customer journey across sales engagement, contracting, on-boarding, operations, issue management, and tracking performance outcomes. With a majority of technical minds, we ran future-facing and empathy inducing activities like newspaper headline creation.

Note: You will see this work referred to as both “KBOps” (knowledge base operations) and “AA” (advanced alerting). These were two product teams converging at this moment.

Three boards from the workshop: human and computer decision making plotted over time, from experts training the system to the masses using it, and two future press releases the room filled in during the vision warm-up. Writing the launch story first forces the value claim into a sentence before a feature list can hide it, and one of the sheets is the earliest place the name KBOps appears.

The service journey wall in three framings: the sales and setup stretch with its actor lanes, the middle span marked smart factory with the transition chain above it, and the operational end from procedures taken through outcome validation to offboarding. At this distance the stickies read and the lanes show who does what at each stage.

The release ladder in my hand on the second evening. Each horizon is defined by the question it answers and who asks it: the expert at six months, operators at twelve, the business owner at eighteen. The same board carries the capability staircase and the three target accounts, one of which took me to Houston four weeks later.

1. V1 – 6mo: Prove the tech. Can KB reduce my downtime? Identify early adopter customers, talk to sales/CoE teams and alpha partners. Get error codes, IT topologies — devices? networks? restrictions?
2. V2 – 12mo: Scale and operate. Can this scale + learn? Deeper engagement with operators and experts.
3. V3 – 18mo: Improve and deliver. Can we do this in real-time? Ensure business owner is satisfied with resulting metrics and system performance.

The July wall synthesized in December as a matrix: three customer tiers over an eleven-stage user journey, from learning about the offering to refining knowledge. The target accounts, the dates and a colleague's framework were stripped out; what stayed is the structure. It names KBOps as the product.

Workshop whiteboard journey was synthesized into a clean map and shared broadly.

Four weeks after bp Wind went on the Glendale wall as a target account, I was in Houston for two days of customer discovery. That engagement is its own project; it is cited here because it is where the product defined in July met its first real users.

bp Wind

Soon after our workshop, the team flew to Houston to engage with bp's wind energy business. I defined the workshop agenda and goals to understand bp's use-case and alignment to our proposed KBOps ecosystem. Validating with monitoring experts in the context of their turbine control room helped refine the model and move us forward into greater design detail.

From the visit: wind turbine blade sections on the wall, the agenda and sticky notes at the whiteboard, and the opportunity drawn as a sum, megawatt-hours times downtime times the price of generation, plus the value of the service agreement.

The roles of a wind operation drawn on the whiteboard, beside the customer's priorities in a column of sticky notes: the operator on a shift monitoring nine sites and a thousand turbines, the remote technician, the operations center manager, the data scientist, the site and field crews, the performance manager and the auditor.

The service journey mapped with the customer on two whiteboards: blue, orange and green sticky notes along lines and loops of arrows, with a list of what comes next.

The bp Wind ROC ecosystem map.

What the visit produced: a knowledge loop for wind maintenance, from data sources through normalization, observation, correlation and detection, to a scenario generator, reasoning and knowledge, and a person who decides, with the results fed back.

A simplified view of bp's wind turbine maintenance.

The three user types from the primer: the Expert, the Doer and the Overseer. Writing them as industry-agnostic roles let the model hold across any operation, and the same three figures recur on the July workshop walls and the December journey map.

The Expert

These subject matter experts know their operational domain better than anyone. With decades of experience, they provide guidance on processes and technical issues to the business and their peers. Often close to retirement, their organizations are under threat of losing The Expert’s knowledge.

Problems

• Codifying knowledge.
• Collaborating with peers.
• Scaling access to knowledge.
• Receiving feedback & iterating.

The Doer

Doers take action when called upon by the organization. They are on-site and hands-on, performing necessary work while providing “human sensor” feedback into the system. The Doer’s industrial street-smarts complement the The Expert’s book-smarts to refine processes and associated actions.

Problems

• Access to best practices.
• Knowing task priority & urgency.
• Contributing field insights.

The Overseer

Overseer’s are accountable for the overall business outcome and performance of the organization. They receive situational status updates and create broad plans to improve aspects of the operation. Overseers work with Experts to translate their plans into codified processes and actions.

Problems

• Connecting strategy to tactics.
• Managing information overload.
• Keeping pulse on operations.

How the three roles meet around a concept: overseers and experts plan together, experts codify and review their work with colleagues, alerts reach the doer and others, and each trigger's feedback loops back into planning.

Iterating

Each trigger records situational data and action feedback to inform planning and refine rule definitions.

Planning

Overseers and Experts collaborate on translating business direction into operational processes that meet performance expectations.

Codifying

Experts associate data streams and write expressions to trigger under conditions. They test and review their work with expert colleagues.

Alerting

Individuals receive notifications when triggered. Doers perform associated actions while others are made aware of the situation.

My first sketch of the rule builder, February 2022. Rules are built from an inserted spreadsheet function, an evaluation and a value, so an expert writes them in a syntax they already know, and the margin notes carry the reasoning. The construct survived unchanged into the hi-fi editor.

Defining multiple rule conditions.

The template backtest sketch, signed 7 February 2022. Before a rule is allowed to interrupt anyone, the expert binds its variables to historical tags, picks a date range and sees where it would have triggered. I designed the trust mechanism before the product. Beside it, the Data panel in two states, empty and bound, with Fred connected to wind speed and Wilma to rotation: how an expert connects a concept to data sources. Wind was the worked example six months before wind was the customer.

The service drawn end to end that autumn: install and configuration, creating a concept template, creating an instance, the rule triggering and the action performed. Existing alerts, data and expert knowledge feed the template at the start, and scenarios, notification responses and actions loop back as later inputs. The feedback loop is the structure, not a feature.

Concept creation and lifecycle diagram.

The v1 wireframe set whole: the screens of each stage of the service in sequence, under the theme get the data flywheel started, with the users who act at each step.

Wireframes indicating needed content and affordances.

The title over the hi-fi screens: high resolution user interfaces for desktop and mobile.

The hi-fi screens under the Advanced Alerting name: the test results at full scroll, beside the library of drafts and published concepts and the notification e-mail on a phone. Fred and Wilma survive from the first sketch as variable names, and the published concepts carry effectiveness scores.

The public record of the release: the March 2024 press release launching the Hybrid AI Platform with KBOps as its knowledge component and PRE delivering alerts and actions, Frost & Sullivan's award naming KBOps, and the company's own account of its origin at NASA JPL and Caltech.

One idea across three records, earliest first: the case-display patent of 2015, Asset Performance Management (2014–2015), and this project (2022). KBOps closes what the earlier work left open: the expert's rule, the doer's procedure, and the feedback between them.