What we believe about how this work should go
The way an integration project is conducted shapes what you end up with as much as the technology itself. This page describes how we think about that.
Back to HomeFoundation
Where this work starts
Most of the difficulty in AI integration is not technical. It is organisational: who will maintain the system when the implementation team leaves, what happens when the alert thresholds drift, how staff know whether the dashboard figures are current. These questions are easier to answer if they are asked before the build begins, not after.
Hagane's working approach grew from noticing where AI projects stopped being used after handover — and tracing that back to specific decisions made early in the engagement. The foundation of our method is a set of commitments made at the start of each project, covering what will be built, who will own it, and how the assumptions behind any projections will be documented.
Core commitments
- Scope and deliverables agreed in writing before work starts
- Assumptions printed where the figures they support appear
- Internal staff trained to maintain the system before close
- Existing routines preserved until new processes are confirmed
Vision
What we think good integration looks like
A well-integrated system is one that continues to function correctly six months after the team that built it has left. It is used by people who understand what it is doing and why. Its outputs are trusted because its assumptions are visible. When something changes — the equipment behaves differently, the terminology shifts, the business needs different metrics — someone inside the organisation knows how to adjust it.
This is a more demanding standard than "deployment complete." It is also the only one that justifies the effort of implementation. We build toward it on every engagement, and we structure our handover process so it is achievable without outside assistance.
The standard we aim for
Still in use, still accurate, still adjustable — six months after we leave.
What we are not aiming for
Deployment that looks complete on a status report but requires a support call within three months.
Core Beliefs
What shapes every decision we make
Agreements reduce surprises
A written scope document is not bureaucracy. It is the mechanism that prevents scope expansion from going unnoticed until the budget is exhausted. Every engagement starts with one.
Visible assumptions are honest ones
Every projection rests on assumptions. The question is whether those assumptions are findable. Printing them beside the figure they support is the minimum standard for honest reporting.
The people who use it should own it
Ownership is not a function of who built something. It is a function of who can maintain and adjust it. Handover procedures exist so that function transfers to the right people before the engagement closes.
Less change is often more reliable
The more a new system departs from existing infrastructure, the more things can break independently of what the integration itself is doing. Working from existing data sources keeps the surface area of change manageable.
Parallel running reduces risk
Replacing an existing process before the new one has been tested under real conditions is the most common way implementation projects create operational disruption. Running both simultaneously until the new system is confirmed removes that risk.
Delivery time matters
A seven-week timeline is not a compromise. It is a constraint that forces prioritisation and prevents scope from expanding indefinitely. Fixed timeframes protect both sides of the engagement from unclear expectations.
In Practice
How beliefs translate into decisions
Belief
Agreements reduce surprises
What this looks like in an engagement
Before the intake process concludes, a scope document is drafted covering what will be delivered, what data sources will be used, what the timeline covers, and what it does not. Both parties sign before technical work begins. Changes to scope are recorded as amendments, not absorbed silently.
Belief
Visible assumptions are honest ones
What this looks like in an engagement
The load table for each service — showing current processing volume, expected volume after implementation, staff time before and after — includes the assumptions behind each figure printed directly beneath the row it affects. These are part of the deliverable, not a footnote to a presentation.
Belief
The people who use it should own it
What this looks like in an engagement
Handover is a scheduled activity within the engagement timeline, not an afterthought. For predictive maintenance: the maintenance team leaves knowing how to adjust alert thresholds. For translation: the document team leaves knowing how to update the terminology base. For dashboards: operations staff leave knowing how to add or redefine metrics.
Belief
Parallel running reduces risk
What this looks like in an engagement
Scheduled maintenance inspection, manual document translation, and hand-assembled morning reports all continue unchanged during the build phase. They are retired only after the new system has been observed working correctly under real conditions, with the client team present.
Human-Centred
The people in the process are not a variable
An alert system that the maintenance team does not trust will be ignored. A translation tool that produces output no reviewer will sign off on will be bypassed. A dashboard that no one understands well enough to question will propagate errors silently. The human side of implementation is not a soft consideration — it is the mechanism by which the technical work produces value or fails to.
Each Hagane engagement involves the relevant operational staff throughout calibration, not just at the start and end. The people who will use the system help define the thresholds, review the terminology, and confirm the metrics. This is not a design philosophy. It is the only reliable way to get to a system that works as intended after handover.
Who is involved at each stage
- Intake — Operations manager and data owner
- Calibration — Staff who will receive alerts or review outputs
- Handover — Staff who will perform ongoing maintenance
- Close — Sign-off from the operational owner
Not involved at any stage
Stakeholders who will not use the system. Their sign-off is not the measure of success.
Innovation
New tools, applied deliberately
The AI tools used in each Hagane service are selected because they can connect to data your systems already produce, perform a specific function well, and can be understood and adjusted by staff who are not machine learning specialists. The selection criterion is fit for purpose, not novelty.
We do not introduce a new platform because a newer one has been released. We update an approach when evidence from real deployments shows the previous one producing worse results. The improvement cycle is driven by what happens in operational environments, not by what is available in research papers.
The question we ask before adding anything
Can the staff who will maintain this adjust it without outside help? If no, we reconsider.
Integrity
What honesty looks like in this work
On projections
Projected figures for processing volume, staff time, and alert frequency are estimates. The assumptions that produce them are documented alongside the figures. If those assumptions change, the figures change. We say this at intake.
On fit
If the intake process reveals that the data available is not sufficient for the service to function as described, we say so before the engagement begins rather than after it ends. Some situations are not a match for what we offer.
On error rates
Alert systems produce false positives. Translation tools produce errors in unfamiliar terminology. Dashboards reflect what the source systems send. Reporting error rates alongside success rates is part of the standard deliverable, not an optional appendix.
Collaboration
Working together rather than for you
The distinction matters practically. An integration built by an external team without close involvement from operational staff produces a system those staff do not understand well enough to maintain. One built with them — their calibration input, their review of alert outputs, their confirmation that the dashboard reflects what they actually need — produces something they can work with and adjust.
Hagane's role in an engagement is to provide technical capability and structure. Your team's role is to provide operational knowledge and authority. The output is neither ours nor yours alone. Both contributions are necessary; the engagement structure is designed to bring them together at the right stages.
What each party brings
Hagane provides
Technical build, calibration process, documentation structure, and handover procedure
Your team provides
Operational knowledge, confirmation of alert quality, terminology review, and metric definition
Together produces
A system that reflects real conditions, is trusted by the people who use it, and can be adjusted without outside assistance
Long-Term
Beyond the close of the engagement
Implementation ends. Operational conditions continue to change. Equipment behaves differently as it ages. Business documents develop new terminology as the company's activities shift. The figures that matter to an operations manager this year may not be the same ones that matter in eighteen months.
The maintenance panel included in each Hagane deliverable describes exactly what ongoing attention the deployed system requires and who is expected to provide it. This is not a pitch for a support contract. It is a realistic account of what it takes to keep the integration accurate over time, so your team can plan for it.
What the maintenance panel covers
- — What the system requires to remain accurate
- — How often each maintenance task needs to occur
- — Which internal role is responsible for each task
- — What to do when something is outside normal parameters
What it does not cover
Ongoing support from Hagane. The intent is that your team does not need it.
What This Means for You
How these principles show up in your engagement
Before work starts
You will have a written scope document covering what will be delivered, what data will be used, what the timeline is, and what assumptions are being made. You can check against it at any point.
During the build
Your operational staff are present at calibration. Your existing processes continue in parallel. You can observe what the system is doing and raise concerns before anything is switched over.
At handover
Your staff leave trained on the specific adjustments they will need to make. Written procedures exist for those adjustments. The engagement does not close until this is confirmed.
After we leave
You have the system, the documentation, trained staff, and a maintenance panel describing what attention it requires. You are not dependent on us to keep it working.
Get in Touch
If this approach sounds like the right fit
We are happy to go over your situation at the intake stage before any commitment is made. If it is not a match, we will say so clearly rather than proceeding anyway.
Start a Conversation