What we believe
Technology should serve people, not the other way around
This page sets out the principles that shape how Nawate works and why we make the choices we do in every engagement.
Back to homeFoundation
What drives our approach
Nawate began with a straightforward observation: many organisations are told that AI will transform their work, but very few are told exactly what that means for a specific task in their specific context. The claims are broad, the implementations are often narrow, and the gap between the two is where most difficulty lives.
We exist to operate in that gap — to take individual tasks, document their real constraints, build something that handles them reliably, and hand it over with enough clarity that the people involved can continue without us.
Fundamental principles
Scope before solution
The constraint document comes before any technical work. Understanding what must not happen matters as much as what should.
Measurement over estimation
We record actual figures from current practice and compare them with actual figures from the integration. Projections are not a substitute.
Control stays with your team
Override, correction, and exception-handling remain with the people doing the work. We do not build dependency.
Philosophy
What we think AI is actually good for
AI is useful at certain kinds of repetitive, rule-based work. It is not useful at everything, and the interesting question — for any given organisation — is not whether to adopt AI but which tasks in which circumstances warrant it. That question deserves a careful answer, not a confident one based on general market enthusiasm.
Our vision is not for AI to be everywhere in your organisation. It is for AI to be in the right places — which may be only one or two tasks — and to be there in a way that is transparent, controllable, and genuinely less effort than what it replaced.
We think the technology works best when it is invisible in operation and unambiguous in responsibility. When something goes wrong — and at some point something will — the person accountable should be obvious and the correction path should be clear.
Core beliefs
What we believe, and why
Belief 01
Honest scope is more valuable than wide scope
An engagement that clearly defines what will be automated and what will not is more useful than one that suggests broad transformation without specifying the mechanism. We believe this, and we build our services around it. The back-office task review exists specifically to produce an honest picture before any integration decision is made.
Belief 02
The people who do the work should understand the system
A scheduler who cannot understand why the system produced a particular roster has less control than they did before. We build against this possibility. The handover process is designed to produce understanding, not just familiarity with clicking a button. If a staff member cannot explain what the system is doing, we have not finished.
Belief 03
Repetition is not the same as low value
Tasks that are performed every day are not necessarily unimportant. Translation errors in supplier communications or scheduling errors that leave a shift under-staffed have real consequences. The argument for automating them is that the repetition introduces its own risks — human attention becomes harder to sustain over thousands of iterations — not that the tasks don't matter.
Belief 04
Some things should not be automated
Customer-facing communications that require tone or relationship context, contractual documents where specific wording carries legal weight, situations where the right answer depends on information not present in the system — these are examples of things that should remain with people. We record them explicitly in scope documentation and we do not push to expand into them.
In practice
How beliefs translate to what we actually do
We write constraints before building
Belief in honest scope means the constraints document is the first output of every engagement — not a slide deck, not a discovery report, but a specific written list of what the system will and will not do.
We measure before we start
Belief in measurement over estimation means we record time and quality figures from current practice before the integration begins. Without a baseline, the comparison figures at handover would have no meaning.
We run parallel periods
Belief that staff should understand the system means they see it in operation before it carries any operational weight. The parallel period is the mechanism for building that understanding through comparison rather than instruction.
Human-centred
The people involved matter more than the technology
The organisations we work with are staffed by people who understand their work in ways we do not. A scheduler knows things about shift preferences, informal agreements, and practical coverage that are not in any system. A translator knows which phrasing carries risk in a particular client relationship.
Our job is to build something that uses what can be systematised and leaves space for what cannot. That is a design choice we make deliberately, not a limitation we work around.
In practice this means
The staff member who currently does the task is involved in the constraints documentation, not just their manager
Override capability is built into the design, not added as an afterthought
Questions and concerns raised during the parallel period are addressed before handover
The handover session is with the people who will use the system, not only the people who commissioned it
Innovation
Thoughtful, not chasing
The AI field moves quickly, and the tools available in July 2025 are different from those available a year ago. We follow those changes and evaluate them, but we do not adopt new approaches because they are new. We adopt them when they produce more reliable results for the specific tasks our clients bring to us.
Continuous improvement in our work comes from paying careful attention to what worked and what did not in previous engagements, and from being willing to change the method when the evidence suggests a better one exists. It does not come from following the general conversation about AI.
How we evaluate new methods
01
Does it produce more reliable outputs for the specific task type?
02
Can a person without technical background maintain it after handover?
03
Does it keep override and correction capability intact?
04
Does it stay within the scope boundary without expanding what it touches?
Integrity
Where we are direct, and why
Prices are stated before contact
Each service has a fixed fee listed on the service page. We do this because we believe the information is yours to have before you decide whether to get in touch. Withholding it to create a conversation is not something we are comfortable with.
We say when something is outside scope
If a task involves too much variability for reliable automation, or if the judgement required is beyond what the technology handles accurately, we say so in the initial conversation. We do not take on work we cannot deliver at the stated standard.
Comparison figures are literal
The figures we provide at handover come from your data and your task, not from industry benchmarks or projected improvements. They represent what actually changed during the parallel period, including cases where the improvement was smaller than expected.
Working together
What the engagement requires from your team
We ask for one contact person who can answer questions about the task and who has authority to confirm the constraints document. For most engagements, that is the main requirement. The parallel period requires your team to use the system and tell us what they observe — this is a short, bounded commitment, not an ongoing one.
We work around your team's capacity as much as possible. We do not require workshops, steering committees, or multiple rounds of review. The constraint is that we do need accurate information about how the task actually works — not how it is documented, but how it is done.
What we bring
Technical implementation of the integration, including configuration and testing
Constraints documentation in clear language, reviewed with your team before build
Management of the parallel period and collection of comparison data
Handover session covering each component and the process for future updates
Documentation in both Japanese and English for all deliverables
Lasting work
Building for the situation after we leave
An integration that requires the original implementer to maintain it is not a durable one. Staff change, priorities shift, and the system needs to continue functioning without someone who was present at its creation. We keep this in mind throughout the build — in the documentation, in the handover session, and in the choice of tools and approaches.
The terminology bases and constraint documents we produce are written to be useful to someone who was not involved in the engagement. The comparison figures are formatted to be read without explanation. The override procedures are documented in the language used by the people who will operate them.
We do not offer ongoing maintenance retainers, because we believe that if the handover is done well, you should not need us to continue. If something changes substantially — a new document category, a change in scheduling rules — the documentation should be clear enough that your team can adapt the system or brief a different implementer.
For you
What these values mean in an engagement
When you work with Nawate, the scope of the engagement is written down before any technical work begins, and it does not expand without a new agreement. The fee is fixed and stated in advance. The parallel period means you can see what the system does before it carries any operational responsibility.
At the end, you receive a system that works, documentation that explains it, and data that shows what changed. The people who will use it will have had the opportunity to ask questions and observe it in operation before the handover.
Our commitment to you
We will tell you if your task falls outside our scope before beginning any paid work
The constraints document is yours to keep regardless of whether the engagement proceeds
The comparison figures will reflect what actually happened, including if the outcome was modest
Handover is not complete until your team can operate and explain the system
Override capability is built in by design, not available on request
Start a conversation
If this approach seems proportionate to your situation
We are happy to discuss a specific task or question. The initial conversation is free of charge, and it begins with us listening rather than presenting.