Research & Discovery · Step 01 · How We Work
Every OpenQCore engagement begins with structured investigation. Before proposing artificial intelligence, automation, software or infrastructure, we study the problem as a system: its objectives, stakeholders, workflows, decisions, data, technologies, dependencies, constraints, risks and measurable outcomes.
Our discovery process combines research, systems thinking, engineering analysis and business reasoning to move from an observed challenge to a defensible problem definition.
Because the first question should not be:
Not this question
"What technology should we deploy?"
This question, instead
"What problem are we actually solving — what evidence supports it, what causes it, and what outcome needs to change?"
Research · Evidence · Systems Analysis · Business Analysis · Measurement
Why Discovery Comes First
Artificial intelligence has become substantially easier to experiment with. Converting experimentation into measurable organizational value remains considerably harder.
74%
of companies had yet to demonstrate and scale tangible value from AI.
BCG, Where's the Value in AI?, 2024 · n=1,000 senior executives.
BCG's 2024 research, based on 1,000 CxOs and senior executives across more than 20 sectors and 59 countries, found that only 26% of companies had developed the capabilities needed to move beyond proofs of concept and generate tangible value from AI.
This does not mean that technology is ineffective. It means technology alone is insufficient.
Organizations can begin with a model, platform or automation technology and only later discover that the underlying constraint lies elsewhere: fragmented processes, inaccessible data, unclear ownership, integration limitations, inadequate controls, poorly defined objectives or a problem that was never measured in the first place.
OpenQCore therefore reverses the sequence: technology should be selected as a consequence of understanding the problem — not as a substitute for understanding it.
A Multidisciplinary Approach
Complex organizational problems rarely belong to a single discipline. OpenQCore investigates them through three complementary perspectives.
Observe · Question · Hypothesize · Test · Validate
Scientific reasoning helps us distinguish observations from assumptions, formulate questions, examine competing explanations and determine what evidence would support or contradict a hypothesis. We do not assume that the first explanation is the correct one.
Systems · Interfaces · Data · Dependencies · Constraints · Reliability
Engineering analysis examines how components interact within the wider system — software, infrastructure, data, humans, processes, interfaces, external systems and operational dependencies.
This perspective is consistent with modern systems-engineering thinking. ISO/IEC/IEEE 15288:2023 defines system lifecycle processes applicable to individual system elements and to systems-of-systems, with stakeholder involvement throughout the lifecycle.
Objectives · Economics · Processes · Risk · Value · Measurement
Business analysis determines why the problem matters. We examine the desired outcome, affected stakeholders, operational impact, economic considerations, organizational constraints and how improvement would be measured.
AI transformation is often discussed primarily in terms of models and algorithms. The implementation evidence suggests a broader picture: BCG's 2024 research reported that approximately 70% of the challenges companies encountered in AI initiatives related to people and processes, approximately 20% to technology, and only 10% to algorithms.
10%
Algorithms
BCG Build for the Future 2024 Global Study · n=1,000.
20%
Technology & Data
BCG Build for the Future 2024 Global Study · n=1,000.
70%
People & Processes
BCG Build for the Future 2024 Global Study · n=1,000.
These percentages are BCG's research framework, not a universal law. But they reinforce an important engineering principle: the model is one component of a larger socio-technical system. For OpenQCore, discovery therefore examines not only the intelligence layer, but the operating environment into which that intelligence would be introduced.
The OpenQCore Research Methodology
Discovery is conducted as a structured sequence of investigation. The exact depth varies with the engagement, but the analytical structure remains consistent.
What outcome matters — and to whom?
We begin by identifying the people, functions and systems affected by the problem. An organization's stated request is not automatically treated as the underlying objective — "we need an AI agent" describes a possible implementation, not yet the business or engineering problem.
We examine
Stakeholders · Decision Owners · Users · Business Objectives · Operational Objectives · Incentives · Dependencies · Conflicting Requirements
Output
Stakeholder & Objective Model
How does the system actually operate today?
We reconstruct the current operating process rather than relying exclusively on how that process is documented. Where appropriate, we establish quantitative baselines for the existing workflow.
Analysis may include
Processes · Tasks · Decisions · Handoffs · Queues · Exceptions · Human Intervention · Bottlenecks · Rework · Information Flow
Output
Current-State Operational Model
What technical environment are we working within?
We examine the architecture surrounding the problem, and investigate the data environment separately. This matters because an AI capability that works experimentally may still be unsuitable for production if the required information cannot be accessed reliably, securely or with sufficient quality.
We examine
Applications · Services · APIs · Databases · Infrastructure · Integrations · Identity · Security · External Dependencies — and data availability, accessibility, structure, quality, lineage, ownership, coverage, freshness and sensitivity
Output
Systems & Data Landscape
What external environment shapes the problem?
A technically valid solution can still be operationally or commercially inappropriate. The scope depends on the engagement — a regulated healthcare system, financial platform and internal productivity tool do not require identical forms of contextual investigation.
Where relevant, we examine
Market Conditions · Industry Structure · Regulation · Technical Standards · Competitive Environment · Technology Landscape · Customer Expectations · External Dependencies
Output
Context & External Environment Model
What limits the solution space?
Constraints are treated as design inputs rather than surprises discovered during implementation. We also explicitly separate known facts, assumptions, known unknowns, dependencies and risks — because uncertainty should be documented, not silently converted into certainty.
We identify relevant
Technical, Operational, Budget and Time Constraints · Security, Privacy and Regulatory Requirements · Organizational Constraints · Adoption Risks · Integration Dependencies · Data Limitations
Output
Constraint, Assumption & Risk Register
What exactly must change?
Discovery converges on a precise problem definition, covering the observed condition, evidence, root causes, affected system, baseline, target state, success criteria, constraints and explicit non-goals.
The definition includes
Observed Condition · Evidence · Root Causes · Affected System · Baseline · Target State · Success Criteria · Constraints · Non-Goals
Output
Validated Problem Definition
The Discovery Cycle
Discovery is not simply a checklist completed once from left to right.
Observe
Analyze
Map
Hypothesize
Validate
Define
Once sufficient confidence has been established: Validated Problem → Strategy & Architecture.
Applying the Methodology
An observed problem and its underlying cause are not necessarily the same thing. Consider a simplified operational example.
Observed condition: Customer requests require 48 hours to process.
Workflow evidence: Requests move through multiple manual approvals.
System evidence: Relevant information exists across disconnected applications.
Data evidence: The same information is repeatedly retrieved and verified.
Root-cause hypothesis: Fragmented workflow and inaccessible information create repeated human work.
At this point, simply adding a conversational interface may improve the customer-facing experience without resolving the underlying processing constraint. The engineering question therefore changes from "How do we add AI?" to "Which intervention changes the causal mechanism producing the undesirable outcome?" — that distinction is central to Research & Discovery.
Observation: Manual document verification is associated with a significant processing bottleneck.
Hypothesis: A controlled document-intelligence workflow may reduce manual review while maintaining required verification controls.
Evidence Required: Representative documents · Existing error rates · Exception patterns · Review requirements · Processing times
Evaluation: Extraction quality · Exception rate · Human-review rate · Processing time · Failure modes
Decision: Support · Modify · Reject the hypothesis
The objective is not to prove that a proposed technology works. The objective is to determine whether the evidence justifies using it.
Define Success Before Implementation
If success is defined only after implementation, almost any result can be interpreted as success. OpenQCore therefore establishes relevant baselines and evaluation criteria during discovery.
Cycle Time
How long does the process take?
Cost per Operation
What resources does each transaction consume?
Error Rate
How frequently does the process produce an incorrect result?
Throughput
How much work can the system process?
Human Effort
How much manual intervention is required?
Reliability
How consistently does the system perform?
Decision Quality
How accurately or consistently are decisions made?
Automation Rate
Which operations can be completed without manual intervention?
Risk Exposure
What operational, security or compliance risk exists?
Experience Metrics
How does the process affect customers, employees or other users?
The structure is simple: Baseline → Intervention → Target → Measurement → Evaluation.
If the desired change cannot be described, the success of the solution cannot be meaningfully evaluated.
AI Requires Contextual Risk Analysis
For AI-related engagements, discovery also examines whether the proposed use of AI is appropriate for the context in which it will operate. NIST's AI Risk Management Framework organizes AI risk-management activity around four functions, and specifically describes risk management as continuous across the AI lifecycle rather than a one-time compliance exercise.
The framework also identifies characteristics associated with trustworthy AI, including validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and management of harmful bias.
Intended Use
Potential Failure Modes
Human Oversight
Data Sensitivity
Decision Consequences
Security
Reliability
Evaluation Requirements
Operational Controls
Governance Requirements
This does not mean every project requires the same governance architecture. Risk controls should be proportionate to the system, its context and the consequences of failure.
Evidence Before Recommendation
We are looking for the intervention that the evidence supports. Recent evidence continues to reinforce the importance of redesigning work rather than simply placing AI on top of existing processes.
~2/3
of organizations had not yet begun scaling AI across the enterprise.
McKinsey, The State of AI: Global Survey 2025.
39%
reported AI-related EBIT impact at the enterprise level.
McKinsey, The State of AI: Global Survey 2025.
The same research identifies workflow redesign as a key characteristic of organizations obtaining greater value from AI — one reason OpenQCore investigates the operating model surrounding the technology rather than treating deployment itself as the objective.
OpenQCore does not begin discovery with a predetermined technical solution. The evidence may indicate that the appropriate intervention is process redesign, systems integration, conventional software engineering, data architecture, workflow automation, analytics, artificial intelligence, or a combination of them. In some cases, the evidence may indicate that building new technology is not justified at all.
OpenQCore does not recommend artificial intelligence because it is fashionable. We recommend it when the problem, evidence, economics and operating constraints justify its use — and we say clearly when they do not.
Problem → Evidence → Requirements → Constraints → Candidate Interventions → Evaluation → Best-Fit Approach — not: AI → Find Somewhere to Use It.
Technology selection follows investigation.
Assumptions are identified rather than presented as facts.
Important conclusions should be connected to the evidence supporting them.
Where uncertainty exists, competing explanations should be considered.
Success criteria are defined before implementation where practicable.
Unknowns and limitations remain visible.
The level of analysis should reflect the cost, complexity and risk of the decision.
What Discovery Produces
Research & Discovery is not intended to end with a presentation full of observations. It should produce artifacts that can inform an engineering decision. Depending on engagement scope, these may include:
The problem context, evidence, observations and principal findings.
Who is affected, who owns decisions and which outcomes matter.
How work and information move through the organization today.
Applications, interfaces, data sources, dependencies and technical constraints.
Evidence-supported explanations for the observed condition.
Current performance against relevant operational or technical indicators.
Functional, technical, operational and governance requirements identified during discovery.
Technical, data, integration and operational feasibility where required.
Potential interventions prioritized according to evidence, value, feasibility and risk.
Known limitations, assumptions, dependencies and material risks.
Targets, metrics and evaluation approach.
The Discovery Decision Gate
The purpose of discovery is not to guarantee that a project proceeds. It is to establish whether it should. A discovery engagement can therefore conclude with one of several directions:
The problem is sufficiently defined, the evidence supports intervention and an engineering path appears feasible.
Important uncertainty remains and additional evidence is required.
The original problem or proposed intervention does not match what the investigation found.
The objective remains valid, but a different technical or operational intervention is more appropriate.
Expected value, feasibility or risk does not justify implementation.
Not building the wrong system can be as valuable as building the right one.
From Research to Architecture
Research & Discovery does not exist separately from the engineering lifecycle. Its outputs become inputs to the next stage: Evidence → Validated Problem Definition → Requirements → Constraints & Risks → Success Criteria → Strategy & Architecture.
Architecture should not begin as a collection of preferred technologies. It should emerge from a defensible understanding of what the system must accomplish, within which constraints, for which stakeholders, at what acceptable level of risk, and against which measurable outcomes.
Step 02
Turn a validated problem into an engineered system direction.
You do not need to arrive with an AI strategy. Bring the operational challenge, technical constraint, research question or business objective. We begin by determining what is actually happening — and what the evidence says should happen next.
Research & Methodological References
We reference these sources directly rather than hide them, because our methodology draws on established principles from scientific inquiry, systems engineering, requirements engineering, business analysis and risk management.
Boston Consulting Group — Where's the Value in AI? (2024)
Based on a survey of 1,000 CxOs and senior executives across more than 20 sectors and 59 countries; the source of the 74% / 26% figures and the 10–20–70 principle referenced above.
McKinsey & Company — The State of AI: Global Survey 2025
Source of the scaling and enterprise-level EBIT impact data, and of the finding on the importance of workflow redesign among higher-performing organizations.
ISO/IEC/IEEE 15288:2023 — Systems and Software Engineering — System Life Cycle Processes
The primary engineering reference for treating systems, their elements, lifecycle and stakeholders in a structured way.
ISO/IEC/IEEE 29148:2018 — Requirements Engineering
Specifies processes and information items for requirements engineering across systems and software lifecycles; ISO confirmed the edition as current following a 2024 review.
NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
Supports contextual AI risk thinking through Govern, Map, Measure and Manage, with continuous risk management across the AI lifecycle. NIST's AI RMF 1.0 is under active revision, which is why we name the version explicitly rather than imply it is always the latest final release.
