TRUST CENTRE / CONTROL LINE
The autonomy level, the human approval, the data handover and what happens when something goes wrong are visible before any contract. We build trust with control points, not with promises.
SEE THE CONTROLS ↓THE LIMITS ARE WRITTEN IN THE CONTRACT
01 / CONTROL MATRIX
Not every build has the same authority. Which step is automatic, which is recorded and which waits for human approval is written down process by process.
Price, contract or quote sending, payment, first contact and data deletion wait for human approval.
A record is kept of who did what and when; on low-risk, reversible steps the previous state is preserved.
A separate environment is set up for each client; no shared client data pool is used.
The scope of the code, data and documentation handover is set out in the contract.
02 / AUTONOMY LIMIT
VUNTUS OPERATING RANGE / 01–03
The systems we build run in the 1–3 range. The exact level is written in the contract, process by process.
Reads the data, makes the state visible and reports. Takes no action.
Prepares the reply or the output; a person checks it and sends it.
Carries out low-risk, recorded and reversible actions.
Moves within written rules; stops at price, money and contract.
Decides without human control. We do not sell this level.
03 / DATA & SECURITY
Ownership, access and activity history are controlled separately. That way trust rests on visible measures, not on a single claim of being “secure”.
“Your data is not held hostage.”
If you leave, the scope of the code, data and documentation handover is written in the contract.
Each user reaches only the area their role requires.
Service keys are kept apart from the application code.
Critical actions leave a trail that can be examined later.
Client work is not merged into a shared data pool.
04 / ERROR SCENARIO
We do not commit that no system ever makes a mistake. This is our commitment: what happens in case of an error, and who steps in, is written down in advance.
An unexpected result is seen from the activity log, not guessed at.
A suspect flow moves into a human queue instead of carrying on by itself.
On actions the scope calls reversible, the previous state is preserved.
A situation that cannot be resolved goes to a predefined role, not to one person.
05 / OPEN POLICIES
Model dependency, the KVKK approach, the frameworks we use and the security reporting channel; written out plainly, without raising the level of the claim.
The system is not tied to a single provider. The model call sits in a layer of its own, apart from the business logic. Changing provider is maintenance work carried out in that layer, rather than building the whole system again.
We refer to the NIST AI Risk Management Framework, the OWASP LLM Top 10 and the guidance of the Turkish Data Protection Authority in our design checklist. This is not a claim of certification.
If you notice a security vulnerability, we ask you to tell us before making it public. We look into the report and share the outcome; we do not run a bounty programme.
Reporting address: info@vuntus.com
OUR LIMITS
NEXT STEP / DISCOVERY
We settle the technical limits, the steps that need human approval and the data handover together, while the scope is still taking shape.