The execution plan behind the proposal: what is built and in what order, how KII's existing systems come in without a rewrite, how the on-premises install is sequenced around the hardware, what the published documentation of every source system actually says, and what has to be true at each gate before the next milestone is invoiced.
KII's people and their agents work in the same place, on the same projects, with the same context — and every change to a production system passes a human approval gate before it lands. The platform is installed on KII's hardware and stays there.
A person and an agent work on the same project with the same files, tasks and context. Not a private chatbot per person — a governed shared workspace.
Sessions are visible to the team according to role, so the team can see what is happening and who is doing it.
Another person picks up a task with full context. Shifts, holidays and handovers stop being a loss of state.
Propose, route, review, approve, apply, receipt. Only an authorised KII role approves a change to a production system.
Every access by named account, every agent proposal and its evidence, every approval, edit or rejection with the approver's identity, and every applied change. KII can read and export it at any time.
The source lives in KII's repository from week one. KII's team, or any engineer KII chooses, carries it forward.
No change reaches a production system without an authorised KII role approving it first. This is not a setting to be tuned later — it is the boundary the whole delivery is built around.
Where KII's production platform runs and how the MIOSA team builds during the engagement are two different things. Keeping them apart is what makes the data-handling position defensible.
KII's platform runs on KII's own infrastructure. Operations requests are served on KII hardware through vLLM — no external provider is needed. Restricted Data is handled only on KII infrastructure or only with KII's internal model, and is never sent to a third-party AI provider.
KII data and code made available to MIOSA are used for the engagement only, and engagement records are kept on MIOSA company-controlled machines and accounts. Access is revoked at the end of the engagement — or at pilot exit if KII stops after Milestone 1.
The shared workspace: projects, tasks, files, sessions. Where a person and an agent meet.
Roles, the approval gate and the audit trail. Decides who may propose, who may approve, and what is recorded.
Data levels control what each role may read and change. KII's data stays on KII infrastructure.
Credentials live in a KII-approved secret store on KII infrastructure. They are never emailed, never shared between people, and removed at exit.
Existing modules in any language, repositories, in-house RAG and current systems keep working where they are and are reached through their own interfaces. The platform orchestrates them and reads them as one context. No risky rewrite underneath.
KII's existing modules, repositories, in-house retrieval setup and current systems, each with an owner and an access decision.
Each asset keeps working where it is and is reached through its own API. Access is read-only, granted system by system.
The system orchestrates the assets and reads them as one context for the team and its agents.
KII's people see one place to work, with the existing estate still running underneath.
| System | Access requested | Phase |
|---|---|---|
| Repositories | Read, then admin on the KII-owned repository for the fork | Milestone 1 |
| Documentation | Read-only, to reuse rather than rewrite | Milestone 1 |
| Internal RAG | Read-only, API | Milestone 1 |
| Operations systems | Read-only, API — the Operations loop | Milestones 1–2 |
| Second department | Read-only, API | Milestone 3 |
| Accounting systems | Read-only, later phase. Migration is out of scope for these 90 days | After Day 90 |
System by system, read-only by default, with a named owner on KII's side for each one. Nothing is connected until its access decision is recorded.
Each milestone is accepted separately, in writing, before the next one is invoiced. Every check is demonstrated on the running system with KII present — evidence, not slides.
NDA and agreement signed, the delivery baseline written, and access requested system by system. The representative cases, named users, second department and documentation coverage are fixed here, so acceptance is measurable without inventing targets.
One week on site, included in the engagement. The environment plan is written with KII's infrastructure owner, and the platform is installed on KII's infrastructure. If the GPU or the vLLM endpoint is not ready, we sequence around it without moving the milestones.
The Operations loop runs end to end on the running system, with a person and an agent on the same project and the approval gate live. If KII decides not to continue after this gate, the engagement stops with no further fees and KII keeps everything delivered to that point.
Operations runs on the platform in production, with cross-user session visibility configured and accepted, and the read-only mirrors from the Operations systems in place.
The second department follows Operations, using the same pattern: read-only access, its own approval roles, its own cases demonstrated on the running system.
Company-wide rollout, handover of source and documentation, and the access-revocation step. KII's team carries it forward from here.
Three paths, chosen by KII: swap in-scope work of equal size at no cost, with the price and schedule unchanged; defer the request to the post-Day-90 roadmap; or add it as a fixed-price change order. Fixed-price change orders only — no hourly billing, ever — and nothing starts unsigned.
The engagement has a single point of accountability, and the plan assumes people get sick and take holidays.
Chief Executive Officer and Engagement Lead. Product architecture, delivery governance, KII decisions, and the acceptance boundary. The single point of accountability for the engagement.
Day-to-day execution, the milestone evidence, and the interface to KII's infrastructure owner during the on-site week.
At least two engineers hold full context and access, so a single absence does not stop the engagement.
Written as we go, not reconstructed at handover.
A weekly record of what was done, what is next, and what is blocked.
MIOSA LLC is the delivery practice and the contracting party for this engagement. The agreement is sent for one signature, with the Statement of Work as Exhibit A and the Data Management Plan as Exhibit B.
The plan is fixed-price and fixed-timeline, so the risks that matter are the ones that could move a date. Each has a response that does not require renegotiating the milestones.
| Risk | Why it matters | Response |
|---|---|---|
| Hardware or GPU not ready | The on-premises install and the vLLM endpoint depend on KII's hardware being available. | Sequence around it without moving the milestones. If it is not ready, KII says so in the information request and the environment plan is written during the on-site week with the infrastructure owner. |
| Access granted late | Read-only access is requested system by system, and each one has its own approval path on KII's side. | Access is requested in the first ten days, in parallel, with a named owner per system. The baseline records what was requested and when. |
| Scope creep mid-engagement | New requests arrive during any 90-day build, and unbounded scope breaks a fixed price. | Swap, defer or add — KII chooses, and nothing starts unsigned. No hourly billing. |
| Acceptance disagreement | "Done" is arguable unless the numbers are fixed before the work starts. | The representative cases, named users, second department and documentation coverage are agreed at kickoff and recorded in the delivery baseline. Every check is demonstrated on the running system with KII present. |
| Key person unavailable | A single-engineer engagement stops when that engineer is away. | At least two engineers with full context and access; runbooks from week one; Friday reviews recorded. |
| Data boundary confusion | Mixing the production zone and the engagement zone would undermine the whole data position. | The two zones are stated separately in the Data Management Plan, with access revoked at exit and credentials kept in a KII-approved secret store. |
| Pilot does not convince | KII asked for a small paid pilot first, and should be able to stop cheaply. | Milestone 1 is the pilot. If KII stops after M1, the engagement ends with no further fees and KII keeps everything delivered to that point. |
| Integration limits under-estimated | Published API rate limits on the source systems can be far lower than assumed. | Design to webhooks where they exist and a scheduled reconcile where they do not, rather than continuous polling. The verified limits are in the research appendix. |
These are open on purpose. The proposal is a draft for discussion, and settling these before signature is what keeps the milestones fixed afterwards.
Whether KII wants a harness built around its own agents and workflows, what it is for, and whether it joins this scope or runs as a separate project. It can front KII's internal model on vLLM, open-source models, or a frontier provider — that choice is KII's.
The exact dates of the week in Zurich. KII's preference is the week of 20 October; Reza is back in Zurich no earlier than 19 October. MIOSA covers its flights and travel; KII covers lodging.
Which department follows Operations in Milestone 3. Fixed at kickoff and recorded in the delivery baseline.
Not part of this engagement. KII runs on its own on-premises infrastructure.
Almost everything is a name, a link, or a date. The request has seven sections, and the day the agreement is signed and these are in hand is Day 0.
| Section | What it covers |
|---|---|
| 01 · Company and contract | Legal entity, legal form (AG or GmbH), registered address, commercial register or UID, VAT number, authorised signatory, billing contact and invoicing requirements. |
| 02 · People and contacts | Who on KII's side owns each decision, and the escalation path. |
| 03 · Systems and access | Repositories, documentation, internal RAG and operations systems, with the access level for each. |
| 04 · Infrastructure | Hardware, GPU and vLLM endpoint, environments, install window, VPN or approved remote access, backup and monitoring expectations. |
| 05 · Data and security | Data levels, who approves what, and the KII-approved secret store. |
| 06 · Operations examples | The representative cases the loop has to handle, and the scheduling constraints. |
| 07 · Roadmap | What follows Day 90, including the accounting systems as a read-only later phase. |
The integration approach — read-only access, webhooks where they exist, a scheduled reconcile where they do not — was checked against the published documentation of the systems involved. Every finding below is tied to the page it was read from. Where a page did not answer a question, that is stated rather than filled in.
read:jira-work, read:jira-user, read:issue:jira, read:issue-meta:jira, read:license:jira.
developer.atlassian.com — scopes
startAt and maxResults, with the response wrapped in a values array.
developer.atlassian.com — Data Center REST intro
jira:issue_created, jira:issue_updated, comment_created.
developer.atlassian.com — Data Center webhooks
page[size], with meta.has_more, after_cursor / before_cursor, and links[next] / links[prev].
developer.zendesk.com — pagination
GET /teams/{team-id}/channels, with optional $filter and $select.
learn.microsoft.com — list channels
llama.com licence links now redirect to the working page.
dev.meta.ai — Llama 3.1 Community License · acceptable use policy
Named read:* scopes on Jira Cloud, revocable personal access tokens on Jira Data Center, OAuth in place of a deprecated API token on Zendesk, and a personal API key on Freshservice. The read-only boundary is a configuration, not a promise.
Jira Cloud's default pool is shared across all tenants, and Zendesk's lowest plan allows 10 requests per minute. Both argue for webhooks plus a scheduled reconcile rather than continuous polling.
So the mirror need not be poll-only. Jira's callback-port and redirect constraints affect where a receiver can be hosted.
Apache 2.0 models can be used without restriction, Gemma adds no commercial clause, and Llama is workable under its community licence with the acceptable-use policy observed. Qwen is unverified.
Provided the licence copy, modification notices, retained attributions and the NOTICE file travel with it, and the original marks are not used to imply endorsement.
A DPIA is likely for a system handling client operations data, the EDÖB consultation has a two-month clock, and both controller and processor keep records of processing.
| # | Question | State |
|---|---|---|
| 1 | ServiceNow auth, rate limits, read-only role | Not researched |
| 2 | Freshservice rate limits and pagination detail | Partial |
| 3 | Microsoft Graph Teams permissions, notification lifetimes, throttling | Partial |
| 4 | vLLM endpoints, API-key auth, 70B-class hardware sizes | Not confirmed |
| 5 | Qwen licence terms | Not retrieved |
| 6 | Autotask maximum page size and total record count | Not confirmed |
| 7 | Jira Cloud maxResults maximum | Not confirmed |
| 8 | promptfoo licence and offline operation | Partial |
| 9 | Vector store scale limits and memory sizing | Partial |
| 10 | GDPR cross-border transfer detail alongside the FADP | Not researched |
Items marked Verified were read directly from the vendor's or the authority's own documentation, and the link is given. Items marked Partial or Not confirmed are exactly that — no figure has been filled in from memory or inference. The four fully open items are the ones worth a follow-up pass before the integration work starts.