What a review board asks, written down first.
The first question about AI-driven development is where your code and your data go.
The first question about AI-driven development is
where your code and your data go.
The items a procurement review asks for, gathered in one place. Individual settings are answered item by item in a security questionnaire. Anything we cannot publish is set out in writing once an NDA is in place.
YOUR SIDE
Your side
- Production environment
- Production data
Releases are handed over through GitHub
WHERE WE WORK
Where we work
- Staging and test environments
- Test data
- Access control, logging, environment separation (Dev / STG / Prod)
Work in production only when the scope, the records and the approval are agreed in the contract
AUTOMATED
Automated work
- An isolated sandbox
- Automated processing by AI
It is not connected to your production systems
HUMAN GATENothing is merged without a human review.
What reaches the AI
Which code and which data may be passed to AI is fixed in writing before work starts. Production data is not used; verification-environment data is.
Automated processing driven by AI runs in an isolated sandbox. It is never wired directly into your production systems.
The model, the processing region, and whether anything is retained for training differ per project. All three are fixed in writing before work starts and recorded in the contract.
Cross-border transfer
Handling personal data in Vietnam needs a stated legal basis under Japan’s personal information act. The legal basis and the safeguards are set per contract type; we explain the detail in writing once an NDA is in place.
Rights in AI-generated code
Copyright in the deliverables is set by the contract. Generated code is never merged without a person reviewing it. The licence check itself is set up to suit the project.
Working to your standards
Access control, environment separation (Dev / STG / Prod), log retention and a review procedure are built into how we develop and operate day to day.
We answer your security questionnaire item by item, in writing. Where something has to be aligned with your internal policy, we agree the scope and the procedure in writing before work starts.
What CI actually checks
Security testing is part of the test phase on every project. It is not an option.
Which of secret scanning, dependency vulnerability scanning (SCA) and static analysis (SAST) are automated is decided against the project’s requirements.
For web applications, OWASP Top 10 is used as a review checklist in design and implementation.
Subcontracting
Who actually touches the source code is named at contract time. Where partners are involved, their scope and permissions are fixed in writing at contract time. We do not subcontract without your agreement.
Access and environment separation
We sign NDAs in Japanese or English. By default we work in staging and verification environments, and releases go through GitHub. Where work in the production environment is required, we agree the scope of access, the logging and the approval steps in the contract beforehand. We apply access control, log management and environment separation (Dev / STG / Prod).
Specific to the AI agent
Once an agent is connected to internal rules and forms, a wrong answer is not the only risk. Prompt-injection handling, per-user permissions on the knowledge base, PII masking and audit-log retention are designed to the configuration and handed over as a design document.
Quality as procedure, not as adjective
We do not promise an accuracy figure before trying it on your data. What we can put numbers to is the part TKS controls: the items below are agreed with you as figures at project start, and reported against at the standing meeting.
- Definition of done for a pull request, and who may approve
- Proportion of code reviewed, and the coverage floor required to merge
- First-response time for an incident, by severity
- How often operating documentation is updated
We name what can go wrong first, and keep a procedure ready for each one.
Aligning on a change of requirement
Where rework most often starts in offshore work
We keep a change register, assess impact, effort and schedule, and obtain your approval. The weekly standing meeting is there to catch changes early.
Not knowing your industry
Time for the project leader to learn your industry’s terms and practices is built into the estimate. We work from your requirements document and glossary.
Communication going astray
Time zone, language, working culture
A contact point on Japan time 10:00–19:00, a shared glossary applied strictly, a weekly standing meeting and a daily stand-up when needed.
Quality varying between people
Individual differences between developers
Standardised through specification-driven development on the TKS-SDD platform. Every change goes through PR-based code review; “it runs, so it is fine” is not accepted.
Information security
Access scope, environment separation and whether any work is subcontracted are fixed in writing at contract time. The detail is on this page.
Trouble at release
A release plan agreed in advance and a staged release procedure. Scheduling that respects Japan time, with a rollback procedure prepared beforehand.
If we cannot do it, you hear it before you sign.
- Static websites, firmware, and hardware-only integration work
- Promising an accuracy or false-alarm rate as a number, before a trial run on your real data
- Staffed 24-hour response; what we provide is the automated part
- Selling hardware — we will introduce a supplier instead
Company
Toward a society where children and older people can live without worry — with our work and FAQ.
Continue