Our beliefs
Integration should
leave you freer,
not more dependent.
This page describes how we think about the work — the beliefs that shape our decisions, and why we do certain things in ways that differ from the norm.
← Back to homeFoundation
Where our approach comes from
Tsumugi was started by people who had spent time on the other side of integration projects — as the staff who inherited systems built by others, and who had to operate them without complete documentation or a clear understanding of what to do when something went wrong.
That experience shaped the core question we ask about every project: will the people who run this system after we leave be able to operate it, understand it, and change it without calling us?
If the answer is no, the project isn't finished. That's the foundation everything else is built on.
"A system that requires its builder to remain available is not a complete piece of work."
— Working principle at Tsumugi, used in project reviews since 2021
2019
Founded in Tokyo consulting
Kansai
Primary working region
Philosophy
What we believe integration work should be
Integration is most often discussed in terms of what it produces — faster processes, connected data, less manual work. Those outcomes are real. But they're not the whole picture. How the work is done, and what the organisation is left with at the end, matters as much as the output itself.
Transparency
The work we do should be explainable in plain language to the people who will operate it. If we can't describe it clearly in a handover document, we haven't finished it.
Proportionality
Not every integration problem requires a complex solution. We scope work to fit the actual problem, not to the maximum the client might accept.
Permanence
What we build should function without us. That's not a selling point — it's a measure of whether the job was done properly.
Core beliefs
The things we won't negotiate on
Existing systems have earned their place
The systems organisations run every day represent years of adaptation. Staff have learned how to work with them, and those systems reflect real operational history. We don't treat that as an obstacle. We build around it.
Evidence should precede commitment
A new system should demonstrate consistent results against real operations before the old one is retired. This is why parallel running is not optional in our work — it's the mechanism by which confidence is earned, not assumed.
Ownership must transfer completely
Documentation and training are not afterthoughts. They're the deliverable. A connection that works but cannot be operated or adjusted by the client team is an incomplete project, regardless of how well the connection itself performs.
Failure modes should be designed, not discovered
Every connection will encounter records it cannot process. Deciding in advance what happens in those cases — how they're flagged, stored, and reviewed — is part of building the connection, not a problem to solve later.
Scope is a commitment, not an estimate
When we agree scope at the outset, that agreement shapes the price and timeline. Discoveries during the build phase don't revise the original commitment. If something is outside scope, we say so clearly before starting.
The path back matters as much as the path forward
Every engagement includes a defined rollback path. If a connection is withdrawn later — because circumstances change, because the business changes — returning to the prior state should be straightforward and documented.
In practice
How beliefs shape the work
Belief → Practice
Existing systems have value
→ We build connections between your current tools. No replacement is proposed unless a system genuinely cannot support the connection needed.
Belief → Practice
Evidence before commitment
→ Old and new processes run in parallel until figures match consistently across live operations, not against test data.
Belief → Practice
Ownership must transfer
→ A named ownership panel, plain-language documentation, and staff training are produced before the project closes — not promised for later.
Belief → Practice
Failure modes designed in
→ Error handling is defined during the mapping phase, before build begins. Unprocessable records are flagged on a schedule, not discovered in a report.
Belief → Practice
Scope is a commitment
→ Fixed-duration projects with fixed prices. The field map is agreed before the build starts. Scope changes are discussed as scope changes, not billed as extras mid-project.
Belief → Practice
The path back matters
→ A rollback procedure is documented during the mapping phase and verified before handover, so withdrawal of the connection is always executable.
People first
The work is done by people, for people
During discovery, we ask to speak with the staff who actually operate the systems in question — not just the person authorising the project. The people who run a process daily carry knowledge about it that rarely appears in specifications.
We design for the person who will be at the terminal at 8am when something unexpected happens. Documentation is written for them. Training is designed for them. The ownership panel names them specifically.
This isn't sentiment. It's the practical reason why systems built with operator input tend to have better-defined error handling and more realistic parallel running periods than those designed at the management level alone.
We speak with operators, not just decision-makers
Discovery conversations include the people who run the system on a typical Tuesday, not only the people who approved the project.
Documentation is written for operators
Handover documentation describes what to do, not just how the system was built. The audience is the person operating it, not the person who could rebuild it.
Training covers adjustment, not just operation
Staff leave the project able to make small changes themselves — adjusting thresholds, adding fields, updating schedules — without needing to involve us.
On technology
We're cautious about novelty
The AI integration space produces a significant volume of new tools, frameworks, and approaches each year. Most organisations don't benefit from adopting each of them. What they benefit from is a stable, well-understood connection between their systems that the people running it can maintain.
We use established approaches where they work and newer methods where the evidence supports them. The measure is always the same: will this be maintainable by the client team after handover, and will it continue to function reliably over the medium term?
What we use
Methods that are well understood, can be documented in plain language, and can be adjusted by staff who did not build them originally.
What we avoid
Approaches that require ongoing specialist involvement to operate, that cannot be explained in the handover documentation, or that add complexity without corresponding benefit.
Honesty
What we tell clients that others sometimes don't
When a problem is outside our scope
If a project requirement falls outside what we do well, we say so at the proposal stage rather than accepting it and adjusting later.
When integration may not be the right answer
Some processes that appear to need automation are better addressed through a change in how the process is structured. We say this when it's true.
What the detection rates actually mean
For quality inspection work, we report measured rates per defect category, not headline accuracy figures. What a model misses matters as much as what it catches.
When the timeline is too short
If an organisation needs a result faster than the parallel running period allows for responsibly, we say so before accepting the engagement, not after the pressure starts.
When results from the trial period look unusual
If parallel running produces inconsistent results, we report them as inconsistent. The trial period ends when the results justify ending it, not on a fixed date.
What the fixed price does and doesn't cover
We describe scope clearly in the agreement and hold to it. Items outside scope are identified before they become issues, not billed as overruns.
Working together
Integration as a shared process
Integration projects that are delivered to organisations — handed over as finished products — tend to be adopted slowly, understood poorly, and abandoned eventually. Projects that are built with organisations tend to be different.
We involve staff at the points where their input shapes the outcome: in discovery, when we're understanding the process; in mapping, when we're deciding how fields correspond; and in parallel running, when we're comparing old and new results together.
By the handover, the people who will operate the system have already been working with it. There is no surprise at go-live.
Staff involvement by phase
Discovery
High
Mapping
High
Build
Low
Parallel run
High
Handover
High
Looking ahead
What we hope a project leaves behind
Six months after a project closes, we hope the organisation has a system that functions reliably, that its staff can explain to a new colleague, and that can be adjusted when something changes in the business. We hope they haven't had to call us.
We also hope the people who went through the project have a clearer sense of what integration work actually involves — what to ask for next time, what to look for in a proposal, and what questions to ask about scope, documentation, and ownership before agreeing to anything.
An organisation that understands integration work better than before is, in the long run, less likely to have expensive problems with it. That seems like a good thing to leave behind.
For you
What this looks like as a client
Before the project
You'll receive a clear scope document before work begins. The price, timeline, and deliverables are stated, not estimated. Questions about what's included have direct answers.
During the project
Your staff are involved at the points where their knowledge shapes the outcome. The field map is reviewed with you before build begins. Parallel running is done with your team, not reported to them.
After the project
You hold the documentation, the ownership panel, and the rollback procedure. Your staff have been trained on operation and adjustment. There is no support contract because there shouldn't need to be one.
What's next
If this approach sounds right for your situation
We're happy to have a direct conversation about what you're dealing with. Describe the systems you're working with and where the friction is, and we'll respond with a clear view of whether it's something we can help with.