KII Custom Module Development on BusinessOS: proposal and scope of work
Custom modules for KII,
built on BusinessOS.
Owned by KII.
Operations first, on-prem, human-approved. A 90-day engagement to develop KII's modules within MIOSA's BusinessOS product, install the KII Platform on KII's own infrastructure, prove it on the Operations loop, and hand over the source in KII's repository.
The engagement
90 days
Four milestones. One on-site week in Zurich. One system KII owns.
A small paid pilot comes first. After Milestone 1, KII may stop and keep everything delivered to that point.
Prepared for
Dr. Reza Kordi
Managing Director, KII
Prepared by
Roberto H. Luna
Chief Executive Officer and Engagement Lead
MIOSA LLC
MIOSA LLC. Agency MIOSA is the delivery practice of MIOSA LLC.
Date and status
October 6, 2026
Draft for discussion
Our position
KII owns the system. Operations proves it. Nothing in production changes without approval.
KII is not buying seats, a chatbot, or another tool to grow out of. It is commissioning custom module development on BusinessOS, starting with the Operations module, running on KII's own infrastructure, reusing KII's existing work, and staying under KII's control.
01 / OWNERSHIP
KII owns the system
KII receives a fork of the BusinessOS platform under the Apache License 2.0 in KII's own repository, plus every KII-specific module, configuration, and document produced in the engagement. It can be rebranded as KII's own platform.
02 / OPERATIONS FIRST
A small vertical, proved early
Phase 1 starts with Operations: real signals, tickets, cases, and time billing, read through a mirror and run behind a human approval gate. The loop is proved on mirrored data before it goes near production.
03 / NO DISRUPTION
Current tools keep running
Autotask, KII's own ERP, ticketing, and Microsoft Teams stay in place. The system reads through read-only mirrors and proposes changes. A person approves before anything is applied.
TODAY
Many tools, scattered context
Autotask, the ERP, tickets, Teams, repositories, and AI experiments, each holding part of the picture.
→
DAY 90
One KII platform on KII hardware
Shared project context for people and agents, governed by role, with a person approving every production change.
→
AFTER
KII owns it and keeps building
Source in KII's repository. KII's team, or any engineer KII chooses, carries it forward.
A small paid pilot first, as requested: Milestone 1 covers mobilization and the Operations pilot. If KII decides not to continue after Milestone 1, the engagement stops with no further fees and KII keeps everything delivered to that point.
One page, the whole engagement
Ninety days, four milestones, one on-site week, one system KII owns.
Everything the engagement contains: what KII buys, when it happens, when money moves, and what KII walks away with.
90 daysSignature to full handover
4Milestones, each accepted separately
1 weekOn site in Zurich, included
0Production changes without approval
DAYS 0-30Mobilize and Operations pilot on mirrored data
DAYS 30-45Operations live with real users and Teams
DAYS 45-70Second department wave, SOP, documentation
DAYS 70-90Company rollout, runbooks, full handover
WHAT KII GETS
Owned, installed, documented
- BusinessOS fork in KII's repository, Apache License 2.0, rebrandable.
- Every KII-specific module, configuration, and document produced.
- Foundation installed and running on KII's own infrastructure.
- Operations loop live with the approval gate enforced.
- A second department wave, with SOP and documentation completed.
- Runbooks, admin training, and a passed restore drill.
THE ON-SITE WEEK
Target week of October 20, 2026
Three to five working days in Zurich, included in the engagement. The team learns Operations from the people who do it, and KII sees how the team works before the larger milestones. Lodging for the week is open to discuss.
THE FIRST STEP
A small paid pilot
As KII asked for. After Milestone 1 acceptance, KII may stop with no further fees and keep everything delivered to that point. Pricing is on the Commercials page.
What does not happen: no change to a production system without a KII approval, current tools keep running behind read-only mirrors, and KII data stays on KII infrastructure.
Reading order
What this document covers.
Companion documents: the Data Management Plan covers data handling, residency, and disposal. The Client Information Request and Roadmap records KII's requirements and the sequence after Day 90. Once KII has reviewed the work, MIOSA sends the agreement for one signature, with the Statement of Work as Exhibit A and the Data Management Plan as Exhibit B. This document is the proposal and the scope of work.
01
Proposal and Scope of WorkThis document: what KII buys, the scope, the timeline, the commercials, and the decision.02
Services AgreementThe next step after review. One signature, with the Statement of Work as Exhibit A and the Data Management Plan as Exhibit B.03
Data Management PlanData handling, residency, Restricted Data, and disposal.04
Information Request and RoadmapKII's requirements and the sequence after Day 90.
The company and the loop
A small team, deep client relationships, and a working loop that deserves better tools.
KII TODAY
A boutique Swiss network engineering firm
- 12 people, with every function present in minimal form.
- About 20 long-term clients and strong relationships.
- Minimal marketing and no push to grow quickly.
- Developers are loaded with client projects and have no time to build internal tools.
- In-house AI experiments in Java and Python with no governance around them.
WHAT KII ASKED FOR
One system, owned by KII, that improves with KII
- Governed shared project context: people and agents on the same project, sessions visible, work can be taken over.
- Operations first, as a small vertical slice that proves it works.
- Reuse existing repositories and documentation instead of starting from interviews.
- No disruption to live operations, with a human in the loop before any production change.
- On-prem throughout, in KII's own data center.
01
SignalA client signal arrives from monitoring, a person, or a Teams message.02
TriageThe team classifies what it is and how urgent it is.03
TicketThe work becomes a tracked ticket with an owner.04
CaseRelated tickets and history collect into a case for the client.05
ResolutionAn engineer resolves it against the client's environment.06
Time billingThe time is captured and billed from the record of the work.
The stated risk, answered directly: KII does not want another tool the team invests time in and eventually outgrows. This system is not rented. KII owns the fork, the modules, and the documentation, so the tool grows with the company instead of being replaced.
KII-controlled production boundary
On-prem by default. Read-only by design. Human-approved before anything changes.
01 / SOURCES
KII's current estateAutotask and KII's own ERP, ticketing, time billing, Teams via Microsoft Graph, repositories and documentation, and in-house RAG.02 / MIRROR
Read-only mirror layerCurrent systems keep running. KII's Autotask and ERP mirrors are configured and accepted in Milestone 1.03 / THE KII PLATFORM
Workspaces and contextWorkspaces, company glossary, shared project context, and agents on KII's internal vLLM model.04 / APPROVAL GATE
Authorized KII roleAny change to a production system is proposed, reviewed, and approved by an authorized KII role first.05 / PRODUCTION
Apply with a receiptApproved changes are applied to production systems and recorded, with the approver and the time.
Runs on KII hardware
The KII Platform is KII's deployment of BusinessOS with the KII modules. It runs on-prem in KII's own data center, with no public cloud dependency for operations.
Internal model for operations
KII's production platform runs on KII's internal model served via vLLM, on KII infrastructure. Frontier models are not used in KII's production platform; KII allows them only for research.
Teams stays
Microsoft Teams remains in place. The Teams connector for KII is configured and accepted in Milestone 2, through Microsoft Graph, which KII already uses.
Why the mirror layer matters: a read-only mirror means the system can learn from real operational data without touching production. Current tools are never put at risk while the new loop is proved.
Honest disclosure
KII's platform never leaves KII. Our own team uses AI tools to work faster.
Two separate things, and it matters that they are not confused: where KII's production platform runs, and how the MIOSA team builds during the engagement.
KII INFRASTRUCTURE / PRODUCTION
Where KII's platform runs
KII's production platform runs on KII's own infrastructure with KII's internal model served through vLLM. This engagement does not change that.
Restricted Data is never sent to a third-party AI provider.
Restricted Data is handled only on KII infrastructure, or only with KII's internal model.
MIOSA ENGAGEMENT TOOLING / DEVELOPMENT
Where our work during the engagement happens
MIOSA company-controlled machines and accounts: engagement records (recordings, transcripts, documents, exports, working copies), kept only for the duration of the engagement.
Ollama Cloud, under a no-data-retention configuration: open-source development models.
United States frontier providers, for example Anthropic's Claude: development, code generation, analysis, documentation, and organizing project information.
THE BENEFIT
Substantially faster delivery
AI tools let a small senior team deliver at a speed and a cost a manual team cannot match. KII receives that speed inside the fixed price and the 90-day term.
THE RISK, STATED PLAINLY
Processing may happen in the US
KII data and code made available to MIOSA may be processed by these providers, including in the United States. MIOSA cannot guarantee an air-gapped engagement.
KII'S CONTROL
Restricted Data stays home
KII may classify any data as Restricted Data. Restricted Data never reaches a third-party AI provider and is handled only on KII infrastructure or with KII's internal model.
No training on KII data, and deletion at the end: MIOSA does not use KII data to train any model and selects providers whose commercial terms do not permit training on submitted data. Within 30 days of completion or termination, MIOSA deletes all KII data and working copies, including copies of deliverables it holds, and certifies deletion in writing on request. KII remains responsible for the notices or consents its own clients require under Swiss FADP and EU GDPR, and for its Restricted Data classification.
People and agents, one workspace
People and agents work in the same workspace, on the same project.
This is the capability KII responded to first: not a private chatbot per person, but a governed place where the team and its agents share context, and where work can change hands without losing anything.
Shared canvas
Phase 1 delivers a shared canvas where a person and an agent work on the same project, with the same files, tasks, and context.
Cross-user session visibility
Configured and accepted in Milestone 2: sessions are visible to the team according to role, so the team can see what is happening and who is doing it.
Takeover with full context
Another person can take over a task with full context. Shifts, holidays, and handovers do not lose the reasoning behind the work.
Company glossary
Every person and agent uses KII's own terms. The glossary is part of the system, so agents speak KII's language, not a generic one.
01
OpenA person opens a session in the project workspace.02
Work with an agentThe agent works from the same project context and glossary.03
Visible by roleThe session is visible to the team according to role.04
Take overA colleague picks up the task with the full context.05
PersistContext, decisions, and history stay in the workspace.
One shared project context: files, decisions, glossary, and history sit under every step above. A handoff changes who is working, never what is known.
On-prem team sync: Phase 1 delivers on-prem team sync, so the shared workspace and session visibility run inside KII's own data center. Data does not leave KII's infrastructure.
Control at three levels
Three levels of control. One approval gate before anything changes.
Layer 1 / User
Every person and every agent has a named identity. Access is explicit, and nothing acts anonymously.
Layer 2 / Role
Permissions follow KII's roles. A user sees and can do what their role allows, not more. Roles are KII's roles, recorded in the system.
Layer 3 / Data
Data levels control what each role may read and change. KII's data stays on KII infrastructure.
The gate
No change reaches a production system without an authorized KII role approving it first.
01
ProposeA person or agent proposes a change to a production system.02
RouteThe proposal goes to the authorized KII role for that system and data level.03
ReviewThe reviewer sees the proposed change, its source, and its effect.04
ApproveOnly an authorized KII role approves the change.05
ApplyThe approved change is applied to the production system.06
ReceiptThe change, the approver, and the time are recorded.
The rule that does not bend: the approval gate is enforced by the system, not by convention, and it is tested as an acceptance criterion in Milestone 1.
Reuse, not rewrite
KII's existing work comes in through APIs. Nothing is thrown away.
KII asked how its existing modules come into the system. The answer is API-first integration: existing code, repositories, experiments, and documentation are reused as the starting point, not replaced.
01
KII's existing estateModules in any language, repositories, in-house RAG, and current systems.02
Documented interfacesEach asset keeps working where it is and is reached through its own API.03
The KII PlatformThe system orchestrates the assets and reads them as one context.04
One system to the teamKII's people see one workspace, with no risky rewrite underneath.
| Existing asset | How it comes into the KII Platform |
|---|
| Modules in any language | Existing modules in Java, Python, or any other language connect through documented APIs. The code is reused, not rewritten. |
| Existing repositories | Reused as the working base. The system reads the code and context that already exists. |
| In-house RAG work | Reused as a source so KII does not end up maintaining a second knowledge base. |
| Current systems | Autotask and KII's ERP come in through read-only mirrors, configured and accepted in Milestone 1. |
| Teams | The Teams connector for KII is configured and accepted in Milestone 2, via Microsoft Graph. |
| Documentation | About 30 to 40 percent complete today. MIOSA helps complete it in parallel during delivery. |
Documentation completed in parallel: the system never depends on undocumented knowledge. Documentation is finished alongside delivery, not left for later.
Nothing is migrated blindly: existing modules keep working where they are, so KII's team sees one system without a risky rewrite.
No lock-in, no outgrowing
KII owns its fork, its modules, and its documentation.
| Layer | License and ownership | Where it lives | What KII can do |
|---|
| BusinessOS fork | Licensed to KII under the Apache License 2.0. KII's fork of BusinessOS. | KII's own repository | Operate, modify, rebrand, extend, and continue without MIOSA. |
| Optimal Engine component | Licensed to KII under the Apache License 2.0. | In KII's repository and in the open | Use, inspect, and replace. No lock-in. |
| KII-specific modules and configuration | Belong to KII on payment of the related milestone. MIOSA makes no claim to them. | KII's repository | Keep, change, and reuse freely. |
| KII documentation | Belongs to KII. | KII's repository | Keep and extend. Completed in parallel during delivery. |
| KII data | Belongs to KII. | KII infrastructure | Handled under the Data Management Plan. Restricted Data stays on KII infrastructure. |
| OSA Agent (agent harness) | Apache License 2.0. | In the open | Use, run with any model, and customize at KII's discretion. See Options to discuss. |
| MIOSA infrastructure platform | A separate MIOSA product with its own agreement. Not part of this engagement. | MIOSA's infrastructure | Not needed. KII runs on its own on-prem infrastructure. Using MIOSA's platform would be a separate agreement. |
Open source, Apache 2.0
BusinessOS, Optimal Engine, and the OSA Agent harness. Free to use, change, and keep.
KII's fork, in KII's repository
Rebrandable as KII's own platform, from kickoff.
Owned by KII
KII's modules, configuration, documentation, and data. MIOSA makes no claim to them.
This engagement is application development. MIOSA develops KII's modules on BusinessOS and contributes to KII's fork only with KII's permission. The source is always in KII's repository, and ownership of KII-specific work product transfers to KII on full payment of the related milestone. The MIOSA infrastructure platform is a different product and is not part of this engagement.
REBRANDABLE
KII's own platform
KII can rebrand the system as its own platform, for example KII Management Platform, with KII's name and identity.
NO OUTGROWING
The tool grows with KII
Because KII owns the fork and the modules, the system improves with KII rather than being replaced when it stops fitting.
Fixed scope
One company, one foundation, four milestone waves.
DAYS 0-30Mobilize and Operations pilot on mirrored data
DAYS 30-45Operations live with real users and Teams
DAYS 45-70Second department wave plus SOP and documentation
DAYS 70-90Company rollout and full source handover
IN SCOPE
- KII only, with Operations as the first vertical.
- Foundation installed on KII's own infrastructure.
- Mirror layer for Autotask, KII's ERP, ticketing, and time billing.
- Teams connector via Microsoft Graph.
- Shared project context, glossary, and governance at user, role, and data levels.
- A second department wave chosen at kickoff.
- SOP and documentation completion, runbooks, and admin training.
- Full source handover in KII's repository.
OUT OF SCOPE
Unless separately contracted, the following are not part of this engagement:
- The cybersecurity company in the group.
- The Vietnam operation.
- The Hong Kong project.
- Accounting system migration. Accounting is integrated read-only later and migrated in a later phase on the roadmap.
- Additional on-site weeks beyond the one included.
- Expansion to other group companies.
Pilot exit: after Milestone 1 acceptance, KII may stop with no further fees, keep everything delivered to that point, and require MIOSA to dispose of KII data per the Data Management Plan. Scope does not expand silently; added work is agreed in writing.
A request outside this scope has a defined path: see Change control on the next page. Request in writing, an impact assessment within three business days, then swap, defer, or add.
If KII wants more than the agreed scope
Ask in writing. Get an answer in three business days. Choose swap, defer, or add.
A fixed price only stays fixed if the boundary is real. Here is exactly what happens when a request falls outside the signed scope.
01 / REQUEST
KII asks in writingThe request names the outcome KII wants. A message, a meeting, or a demo is a conversation, not a scope change.02 / ASSESS
MIOSA answers within 3 business daysMIOSA returns the scope, the fixed price, and the schedule effect in writing.03 / DECIDE
KII chooses a pathSwap, defer, or add. Nothing starts before the choice is made and signed.
PATH 1 / SWAP
Trade, at no cost
Trade out in-scope work of equal size for the new request. The price does not change and the schedule holds.
PATH 2 / DEFER
Move it to the roadmap
The request moves to the post-Day-90 roadmap and is priced and scheduled when KII is ready for it.
PATH 3 / ADD
Fixed-price change order
MIOSA issues a fixed-price change order. Work starts only after it is signed. No hourly billing, ever.
THE RULES
- Fixed-price change orders only. No hourly billing.
- Nothing starts unsigned. Work outside the signed scope is never started on a promise.
- Messages, meetings, demos, and proposals never expand scope on their own.
- Change orders are billed on signature unless the order states otherwise.
- Dates move by the length of the delay when KII dependencies (access, decisions, examples, reviews) are late.
TYPICAL OUT-OF-SCOPE REQUESTS
- A new department beyond the waves agreed in this scope.
- Accounting system migration, which sits later on the roadmap.
- Another group company, for example the cybersecurity company, the Vietnam operation, or the Hong Kong project.
- New integrations that are not listed in the scope.
- Additional on-site weeks beyond the one included.
Why this protects KII too: a fixed price with a real boundary is what keeps four milestones and 90 days honest. Silent scope growth is what turns a fixed-price project into an open-ended one.
Day 0 is signature
Ninety days, four accepted milestones, target dates confirmed at kickoff.
DAY 0
SignatureM1 invoiced at signature
USD 30,000
DAY 30
M1 acceptedOperations pilot on mirrored data
Pilot proved
DAY 45
M2 acceptedOperations live with real users
USD 30,000
DAY 70
M3 acceptedSecond department wave live
USD 30,000
DAY 90
M4 acceptedRollout, runbooks, full handover
USD 30,000
Pilot exit point, after M1 acceptance: KII may stop with no further fees, keep everything delivered to that point, and require MIOSA to dispose of KII data per the Data Management Plan. USD 90,000 of the fee is never invoiced if KII stops here.
| Gate | Window | Working output | Acceptance evidence | Payment |
|---|
| Mobilize | Days 0 to 10 | NDA signed, and the agreement signed once with Exhibit A and Exhibit B attached, registration documents provided, access to repositories and documentation, environment plan, interviews scheduled. | Signed documents and confirmed access. | Included in M1 |
| On-site week | Target week of Oct 20 | Operations audit, company glossary, Operations workflow mapping, install of the foundation on KII infrastructure. | Foundation running on KII infrastructure. | Included |
| M1 Operations Pilot | Day 30 | Operations pilot running on mirrored data with human approval gates. | Pilot demonstrated with the approval gate enforced. | USD 30,000 at signature |
| M2 Operations Live | Day 45 | Real users, Teams integration via Microsoft Graph, shared project workspace with session handoff, role and data governance. | Named users working daily, takeover demonstrated. | USD 30,000 on acceptance |
| M3 Second Wave | Day 70 | Second department wave (chosen at kickoff), plus SOP and documentation completion. | Second department live, SOP accepted. | USD 30,000 on acceptance |
| M4 Rollout and Handover | Day 90 | Remaining in-scope departments, runbooks, admin training, full source handover in KII's repository. | Runbooks, training, and source handover accepted. | USD 30,000 on acceptance |
Weekly rhythm
- 30-minute interviews with team members.
- Friday review with KII, 30 to 60 minutes.
- Written weekly status.
- Recorded decisions.
Gate discipline
- No silent scope change.
- No production change without approval.
- No milestone accepted without evidence.
- Target dates confirmed at kickoff.
Each milestone is measured, not claimed
Every milestone is accepted against a concrete check.
| Milestone | Acceptance check |
|---|
| M1 Mobilization and Operations Pilot | The foundation is installed and running on KII infrastructure. The Operations pilot runs on the mirrored data for the representative cases agreed at kickoff. The approval gate is enforced on every production-bound change, and the company glossary is accepted. |
| M2 Operations Live | The named users agreed at kickoff are working daily in the workspace. Teams context is visible through the Microsoft Graph connector. A task takeover with full context is demonstrated. Role and data governance are enforced. |
| M3 Second Department Wave | The second department chosen at kickoff is working in the system. SOP and documentation are completed to the coverage agreed at kickoff and accepted by KII. |
| M4 Company Rollout and Handover | The remaining in-scope departments are live. Runbooks and admin training are accepted. The full source is handed over in KII's repository, and a restore drill is passed. |
01
Agree the numberRepresentative cases, named users, the second department, and documentation coverage, fixed at kickoff.02
DemonstrateEach check is run on the live system with KII present.03
Accept in writingWritten acceptance before the next milestone is invoiced.04
InvoiceUSD 30,000 on acceptance, or at signature for Milestone 1.
Numbers that depend on KII are agreed at kickoff: the representative cases, the named users, the second department, and the documentation coverage are confirmed with KII at kickoff and recorded in the delivery baseline, so acceptance is measurable without inventing targets.
Evidence, not slides
Each check is demonstrated on the running system with KII present.
Pilot exit honored
If M1 is accepted and KII stops, the engagement ends with no further fees.
One invoice per gate
Milestone billing only. Four payments of USD 30,000, never hourly.
Who does the work and who stands in
A named lead, a small senior team, and continuity built into the contract.
| Role | Accountability | Status |
|---|
Roberto H. Luna
Chief Executive Officer and Engagement Lead | Product architecture, delivery governance, KII decisions, and the acceptance boundary. The single point of accountability for the engagement. | Named |
| Delivery lead | Day-to-day delivery, schedule, and coordination with KII's named owners. | Named at kickoff |
Senior engineers
15 to 20 years of experience | Implementation and integration of the foundation, mirrors, and modules. | Named at kickoff |
Data management lead
Enterprise data governance specialist | Data Management Plan, mirror layer, data levels, and data residency. | Named at kickoff |
WHO DOES WHAT
| Workstream | KII | MIOSA | Decision rule |
|---|
| Named owners, access, and examples | A | C | KII decides, MIOSA asks on time. |
| Foundation install and Operations pilot | C | AR | MIOSA builds, KII reviews on the running system. |
| Approval gate in operation | A | R | A KII role approves every production change. |
| Milestone acceptance | A | C | Written acceptance before the next invoice. |
| Scope changes | A | R | KII chooses swap, defer, or add. |
| Data handling and disposal | C | AR | Per the Data Management Plan. |
A accountable, decides · R responsible, does the work · C consulted, gives input
Who stands in for Roberto: KII asked this directly. At least two engineers carry full context and access, so delivery does not depend on one person. The delivery lead owns the schedule when Roberto is not on site.
CONTINUITY PRACTICES
- Documentation-first delivery.
- Every decision recorded.
- At least two engineers with full context and access.
- Runbooks maintained from week one.
- Friday reviews recorded.
- Source always in KII's repository.
MIOSA LLC. Agency MIOSA is the delivery practice of MIOSA LLC. The contracting party for this engagement is MIOSA LLC.
To finalize together
A few choices we will settle together before anything is final.
This proposal is a draft for discussion. The items below are open on purpose, so KII and MIOSA can agree what fits before the scope and the agreement are finalized.
OPTION 1 / A CUSTOM AGENT HARNESS
Any model
KII's internal model on vLLM
Open-source models
Frontier models, where KII allows them
→
APACHE 2.0
OSA Agent harness
Agents, tools, and multi-step work
Fully customizable, end to end
KII decides how it runs
→
KII's work
The KII Platform and its modules
KII's repositories and RAG
KII's own workflows
INCLUDED TODAY
Use it as it is
The OSA Agent is open source under the Apache License 2.0. KII and its team can use it at their own discretion, with any model, without asking MIOSA.
OPTIONAL To scope
MIOSA customizes it for KII
If KII wants a harness built around its own agents and workflows, we first agree what it is for. It is then either folded into this scope or scoped and priced separately.
| Open item | What we decide together |
|---|
| Custom agent harness | Whether KII wants a customized harness, what it is for, and whether it joins this scope or runs as a separate project. |
| On-site week and lodging | The exact dates, and lodging for the week. KII may know a good place nearby; how it is arranged and covered is open to discuss. |
| The second department | Which department follows Operations in Milestone 3. |
| MIOSA infrastructure platform | Not part of this engagement; KII runs on its own on-prem infrastructure. If KII ever wants to use MIOSA's infrastructure platform, that is set up under a separate agreement for the platform itself. |
| Final scope and terms | Anything in this draft KII wants to change, before the agreement is sent for signature. |
Fixed fee and milestone billing
USD 120,000 for 90 days. The on-site week is included.
TOTAL ENGAGEMENT
USD 120,000
A 90-day engagement with four milestones, each separately accepted. Exclusive of applicable taxes.
ON SITE
Included
One on-site week in Zurich (3 to 5 working days). Lodging for the week is open to discuss with KII. Additional weeks only by written agreement.
| Milestone | Amount | Invoiced | Target acceptance |
|---|
| M1 Mobilization and Operations Pilot | USD 30,000 | At signature | Day 30 |
| M2 Operations Live | USD 30,000 | On acceptance | Day 45 |
| M3 Second Department Wave | USD 30,000 | On acceptance | Day 70 |
| M4 Company Rollout and Handover | USD 30,000 | On acceptance | Day 90 |
| Total | USD 120,000 | Milestone billing | Day 90 |
Pilot exit: after Milestone 1 acceptance, KII may stop with no further fees. KII keeps everything delivered to that point, and MIOSA disposes of KII data per the Data Management Plan.
Taxes and terms: fees are exclusive of applicable taxes. Invoices are due within 14 days. On exit or completion, KII data is disposed of per the Data Management Plan, and the delivered source stays in KII's repository.
Payment protection: invoices are due within 14 days. If an undisputed invoice is more than 10 days overdue, MIOSA may pause work after written notice, and the schedule extends by the length of the pause. Ownership of KII-specific work product transfers to KII on full payment of the related milestone. The agreement records the full terms and the AI and data disclosure, with the Statement of Work as Exhibit A and the Data Management Plan as Exhibit B. MIOSA sends it for one signature after KII has reviewed the work.
What KII provides, confirmed at kickoff
The fixed fee depends on timely decisions and usable access.
| Area | What KII provides | Confirmed |
|---|
| Named owners | Executive sponsor (Reza), engineering evaluator, business and budget owner, Operations owner, and security owner. | At kickoff |
| Access | Repositories, documentation, Autotask and ERP APIs, Teams via Microsoft Graph, the vLLM endpoint, and a data center environment for install. | Days 0 to 10 |
| Representative examples | Real signals, tickets, cases, and time entries, provided via the mirror and under the Data Management Plan. | At kickoff |
| Time and rhythm | 30-minute interviews per team member and Friday reviews. Year-end is KII's busiest period and is planned around. | At kickoff |
| Data residency | Swiss FADP and EU GDPR. Data stays on KII infrastructure. Remote access only through KII-approved methods. | At kickoff |
| On-site week | Week of October 20, 2026, or the first week Reza is back in Zurich (no earlier than October 19). | At kickoff |
01
Kickoff confirmsNamed owners, representative cases, the second department, and documentation coverage.02
Access opensRepositories, APIs, Graph, the vLLM endpoint, and the data center environment.03
Delivery runsUnblocked work proceeds; blocked work is documented and agreed.04
If an input is lateDates move by the length of the delay. Policy and approval are never bypassed.
ASSUMPTIONS
- KII provides the named owners and access on time.
- The mirror and Teams integration are technically reachable through existing APIs and Graph.
- KII's data center can host the foundation.
- Target dates are confirmed at kickoff.
IF AN INPUT IS LATE
- Delivery works on the parts that are unblocked.
- The schedule impact is documented and agreed.
- Blocked capability never bypasses policy or approval.
- No silent substitution of scope.
From proposal to a signed start
Review the draft. Settle the options together. Start on site.
KII
Before we start
- Review this proposal and the three companion documents.
- Request a call with reference clients if it is useful.
- Name the executive sponsor, engineering evaluator, business and budget owner, Operations owner, and security owner.
- Confirm the on-site week.
MIOSA
At kickoff
- Countersign the agreement sent after review. One signature covers the agreement, with Exhibit A and Exhibit B attached.
- Provide registration documents.
- Open access to repositories and tools.
- Schedule the 30-minute interviews.
- Install the foundation on KII infrastructure and begin the Operations pilot.
REFERENCE CLIENTS
See it working
KII has already seen a live demonstration. On request, KII can speak with owners of comparable systems delivered by MIOSA before signing.
THE SEQUENCE
- Review the work: this proposal, the Client Information Request and Roadmap, and the Data Management Plan.
- Walk through the open options together and settle the final scope.
- Send us the information in the request.
- Your security owner reviews the Data Management Plan.
- MIOSA sends the agreement for one signature, with the Statement of Work as Exhibit A and the Data Management Plan as Exhibit B.
- Grant access, then the on-site week in Zurich, target week of October 20.
The agreement: one document, signed once. The Statement of Work is Exhibit A and the Data Management Plan is Exhibit B, both attached to that single signature. MIOSA sends it after KII has reviewed the work. Change orders are separate written documents, signed only when a change is agreed. Final dates and named roles are recorded at kickoff.
KII's advantage will not come from having more tools. It will come from owning the KII Platform, which knows how KII works, improves with KII, and never changes production without a person approving it.
