KII business OS / Operations first
Make the first 90 days executable, Operations first.
This document turns the proposed engagement into the decisions, access, source material, named owners, and acceptance evidence KII and the delivery team need before implementation starts. Fill it in before kickoff and confirm it in the first Friday review.
90Days, signature to handover
4Milestones, USD 30,000 each
1On-site week in Zurich, included
120USD thousand total, taxes excluded
ON-SITE
One week in Zurich
Included in the price, with travel and lodging covered by MIOSA. Target: the week of October 20, 2026.
RHYTHM
Friday review
A 30 to 60 minute review, a written weekly status, and recorded decisions.
OWNERSHIP
KII owns the platform
Source, modules, configuration, and documentation live in KII's own repository.
How this document is used: KII completes the owner table, the access table, and the policy inputs before kickoff. MIOSA converts the confirmed answers into the environment plan, the access plan, and the acceptance checks for each milestone.
02 Who provides what
06 Department sequence
03 Named owners before kickoff
07 Security and policy inputs
04 Systems and access
08 Readiness and confirmation
05 Representative Operations examples
Roadmap, Day 0 to Day 90
MIOSA LLC. Agency MIOSA is the delivery practice of MIOSA LLC.
WHAT GOOD LOOKS LIKE AT DAY 90
Operations live with real users, a second department live, runbooks and admin training complete, and the full source handed over in KII's own repository.
WHAT WOULD MAKE KII STOP
If the Operations pilot does not earn its place, KII stops after Milestone 1 with no further fees, keeps everything delivered to that point, and MIOSA disposes of KII data as the Data Management Plan states.
Two sides of one engagement
KII brings the business, the access, and the decisions. MIOSA brings the build and the handover.
KII inputsWhat only KII can provide
One named owner per decision, from the owner table on the next page.
Read-only access to the current systems, through KII-approved methods.
A small set of real Operations examples: signals, tickets, cases, time entries.
A data center environment for the install, and the internal model endpoint.
A 30-minute interview slot per team member, and a Friday review slot.
The classification and policy decisions that set the handling boundary.
MIOSA outputsWhat MIOSA delivers and hands over
The foundation installed on KII infrastructure, in KII's own data center.
The Operations vertical slice, with the mirror layer and human approval gates.
Microsoft Teams integration via Microsoft Graph.
A shared project workspace, with session handoff and role-based visibility.
Documentation, the company glossary, SOPs, and runbooks.
Admin training and full source handover in KII's repository by Day 90.
READ IT IN THIS ORDER
Owners, then access, then examples, then the roadmap. Each one unlocks the next.
FILL IT IN BEFORE KICKOFF
The owner table, the access table, and the policy inputs are the inputs to the environment plan.
CONFIRM IT ON FRIDAY
Every confirmed answer is recorded in the first Friday review and becomes the baseline.
One line on change control: fixed-price change orders only, never hourly billing. The three paths KII can take when new work appears are set out on the roadmap page.
Named owners before kickoff
Every decision has one accountable person, not a committee.
Name the person who owns each decision. Where a decision needs a second signature, the second signature is confirmation, not a second owner. Owners are needed by Day 0 unless the table states otherwise.
| Role | Decides | Name (fill in) | Needed by |
|---|
| Executive sponsor | Confirms scope, milestone acceptance, and any change to dates. | | Day 0 |
| Engineering evaluator | Reviews the architecture, integration approach, and technical acceptance. | | Day 0 |
| Business and budget owner | Approves the commercial schedule, invoices, and any scope change. | | Day 0 |
| Operations owner | Owns the Operations pilot, the workflows, and daily user acceptance. | | Day 0 |
| Security and data owner | Approves access methods, data handling, and the Data Management Plan. | | Day 0 |
| Teams and Microsoft 365 admin | Grants Microsoft Graph access and confirms tenant policy for the integration. | | Day 10 |
| Data center and infrastructure owner | Approves the install environment, the network path, and the internal model endpoint. | | Day 10 |
Escalation: any blocked access or policy decision goes to the named owner with a written 24-hour response path. MIOSA records the ruling in the decision log.
Schedule rule: a delay in these client decisions moves the affected milestone, by the length of the delay. The delivery team will not invent authority, data meaning, or acceptance criteria to preserve a date.
How a decision gets made and recorded
01 RAISE
In writing, with an ownerAny decision that affects scope, dates, access, or data is raised in writing and pointed at the named owner.02 RULE
The owner decidesThe named owner makes the call. Where a second signature is needed, it is confirmation, not a second owner.03 ESCALATE
Sponsored within a dayIf the owner is blocked or unavailable, the executive sponsor rules within 24 hours of the written request.04 RECORD
Written into the logMIOSA writes the ruling into the decision log, and the plan, the dates, and the access all move with it.
ONE OWNER, ONE DECISION
A decision with two owners has none. Naming one person per row is the whole point of the table above.
WHAT BLOCKS A MILESTONE
Missing access, an undecided policy input, or an unconfirmed example. Each one moves the date by the length of the delay.
WHAT DOES NOT BLOCK IT
Silence, a meeting, or a message. None of these create authority, and none of them expand the signed scope.
Read-only mirror, the current tools keep running
Connect the current systems without disrupting live operations.
MIOSA reads from the current systems through a mirror layer. Nothing writes to a production system without the approval of an authorized KII role. Access type is stated for each system.
| System | What we need | Access type | Owner | Ready |
|---|
| Autotask | Accounts, contracts, tickets, and time entries for the Operations mirror. | Read-only mirror | | □ |
| KII ERP (in progress) | Current schema, APIs, and a staging environment as it replaces Autotask. | Read-only mirror, API | | □ |
| Ticketing | Ticket sources, status fields, priority rules, and escalation paths. | Read-only mirror | | □ |
| Time billing | Time entries and billing rules tied to tickets and cases. | Read-only mirror | | □ |
| Microsoft Teams via Microsoft Graph | Graph application access to meetings and channels, with tenant consent. | Microsoft Graph API | | □ |
| Repositories | Read access to current code, then a KII-owned target repository for the fork. | Read, then admin on KII repo | | □ |
| Documentation | Existing documentation as it stands, so it is reused and completed, not rewritten. | Read-only | | □ |
| Internal RAG | Current retrieval setup, sources, and embedding approach for reuse. | Read-only, API | | □ |
| vLLM endpoint and model | Endpoint details and the model name that serves operations. | API | | □ |
| Data center environment | Target hosts, network path, storage, and a service account for the install. | Admin, install | | □ |
| Accounting systems (later) | Read-only integration in a later phase. Migration is out of scope for these 90 days. | Read-only, later phase | | □ |
Access readiness, gate by gate
01 OWNER
A name per systemEvery row above has a named KII owner before the request goes out.02 REQUEST
Ask the right wayMIOSA requests access system by system, using KII's approved method only.03 APPROVE
Method confirmedKII confirms the access path, the credential store, and the scope of each account.04 GRANT
Read-only by defaultAccess is granted read-only. Production writes stay behind the approval gate.05 REVIEW
Rechecked at milestonesEvery account is reviewed at each milestone and removed when no longer needed.
Do not send by email: production secrets, shared administrator credentials, or unredacted client data. Credentials are exchanged through KII's approved method and stored under the Data Management Plan.
Measure the system against real work
Prepare a small set of real examples, then confirm the expected result.
SIGNALS
- A set of real signals from client environments
- Expected classification and routing for each
- Known duplicates and ambiguous cases
- Thresholds for an urgent signal
TICKETS
- Open and closed tickets across priorities
- Examples of priority changes
- Escalation and handover examples
- Expected status at each step
CASES
- Representative cases with owner and history
- Resolution notes and linked tickets
- At least one case that went wrong
- Expected summary for each case
TIME ENTRIES
- Time entries tied to tickets and cases
- Billing rules and rounding
- Examples that are unclear or disputed
- Expected billing output
A HANDOVER EXAMPLE
- One task that moves from one person to another
- The context each person needs
- Where the context currently lives
- What full context would include
A CLIENT REPORT
- One periodic report KII sends to a client
- Source data and manual steps
- Review and approval before sending
- Expected content and layout
How these are handled: examples are read through the mirror layer, stay on KII infrastructure for the KII production platform, and are governed by the Data Management Plan. Where an example is shared with MIOSA for delivery work, it is handled under that plan as well.
| Acceptance attribute | What KII confirms | Owner |
|---|
| Correct | What outcome counts as correct, including allowed variance. | |
| Complete | Which fields, evidence, and actions must be present. | |
| Timely | The maximum acceptable response time. | |
| Safe | Which actions require human approval, or are prohibited. | |
KII confirms these four attributes once, and every milestone is measured against them.
Ninety days, four milestones, one rule for anything new
From signature to a governed, owned platform, one department at a time.
DAYS 0 TO 10Mobilize (remote)
ON-SITE WEEKOperations audit and install
DAY 30M1 Operations pilot
DAY 45M2 Operations live
DAY 70M3 Second department wave
DAY 90M4 Company rollout and handover
| Milestone | Days | What is delivered | Acceptance | Invoice |
|---|
| M1 Mobilization and Operations Pilot | Days 0 to 30 | NDA and Data Management Plan countersigned, access, environment plan, 30-minute interviews, one on-site week, foundation installed on KII infrastructure, Operations pilot running on mirrored data with human approval gates. | Operations pilot runs on mirrored data with approval gates, confirmed in the Friday review. | USD 30,000 at signature |
| M2 Operations Live | Day 45 | Real users live, Microsoft Teams integration via Microsoft Graph, shared project workspace with session handoff, role and data governance. | Accepted with real users working in the system. | USD 30,000 on acceptance |
| M3 Second Department Wave | Day 70 | The second department chosen at kickoff, plus SOP and documentation completion. | Department live and SOP accepted. | USD 30,000 on acceptance |
| M4 Company Rollout and Handover | Day 90 | Remaining in-scope departments, runbooks, admin training, and full source handover in KII's own repository. | Handover accepted and admin training complete. | USD 30,000 on acceptance |
Change control: fixed-price change orders only
KII asks in writing. MIOSA returns an impact assessment within 3 business days: scope, fixed price, and schedule effect. KII then chooses one of three paths.
PATH 1 / SWAP
Trade it outDrop in-scope work of equal size and take the new item instead, at no cost. Nothing is added to the price.PATH 2 / DEFER
Add it to the roadmapPut it after Day 90 and plan it as a later phase, quoted separately when KII is ready.PATH 3 / ADD
Sign a change orderSign a fixed-price change order and the work starts only after signature. Billed on signature unless the order states otherwise.
Nothing outside the signed scope is started. Messages, meetings, demos, and proposals never expand scope on their own. Dates move when KII dependencies (access, decisions, examples, reviews) are late, by the length of the delay. After Day 90 is not included in the price: accounting migration, deeper agent automation, and other group companies are each quoted separately. Weekly rhythm throughout: a Friday review of 30 to 60 minutes, a written weekly status, and recorded decisions.
Operations first, then the next wave
One department proves the model, then it spreads on evidence.
WAVE ONE / OPERATIONS
Signals, tickets, cases, time billing
Operations runs through the busiest, most measurable work in the company and every step leaves a record. It is the smallest slice that proves governed shared context in real conditions.
DOCUMENTATION COMPLETION PLAN
30 to 40 percent toward complete, in parallel
- Reuse existing repositories and documentation as they stand.
- Document the Operations workflow as it is mapped on-site.
- Move documentation from about 30 to 40 percent toward complete.
- Company glossary so people and agents use KII's terms.
WAVE TWO / CANDIDATES
Chosen at kickoff
- Service delivery
- Sales and client management
- Administration and finance, excluding accounting migration
The second wave is confirmed in the first Friday review, based on the criteria on the right.
SELECTION CRITERIA
- Enough real signal volume to test the model.
- Systems ready enough to mirror read-only.
- An owner available for the Friday review.
- A measurable acceptance result.
- Low disruption risk to live operations.
- Direct value to the Operations team already live.
Principle: one foundation, then one department at a time. Each wave is accepted before the next begins, so KII always sees a working result before committing more of the organization to it.
WHAT WAVE TWO NEEDS
- A named owner from the department.
- Its systems mirrored read-only.
- Its own representative examples.
- A first Friday review date.
WHAT STAYS THE SAME
- One foundation, one governance model, one glossary.
- The same read-only mirror and human approval gates.
- The same Friday review rhythm.
- The same source handover into KII's repository.
Policy before production data
State the control, then let the platform follow it.
The platform is governed at three levels: user, role, and data. These inputs define the boundary. MIOSA needs each item in writing before production data enters the system.
| Input | What KII provides | Owner | Needed by |
|---|
| Data classification | Levels, labels, which levels may enter the platform and the mirror, and which data is Restricted Data. | | Day 0 |
| Access methods | Approved remote access, network path, and credential handling. | | Day 0 |
| Model usage policy | What the internal model on vLLM may handle, and which data may be used with MIOSA's delivery AI tools. | | Day 10 |
| Retention | How long data is kept, and what is deleted at the end of the engagement. | | Day 10 |
| Incident contacts | Named contacts and the escalation path for a security incident. | | Day 0 |
| Client notification requirements | When and how KII's clients are told who handles their data, including Swiss FADP and EU GDPR cross-border disclosure. | | Day 10 |
| Swiss FADP and EU GDPR | Data residency, subject access, and deletion obligations that apply to KII and its clients. | | Day 10 |
Fixed by design: the production platform runs on-prem in KII's own data center, and Operations use the internal model served through vLLM. Production data stays on KII infrastructure, and remote access follows KII-approved methods only.
Required before production: the security and data owner approves the access methods, the retention rules, and the model usage policy. Until then, only mirrored data in a controlled environment is used.
Where MIOSA's delivery tools sit: MIOSA's team uses commercial AI services, including United States based providers, so KII data shared with MIOSA may be processed outside Switzerland. The Data Management Plan sets out both zones and the Restricted Data rule.
GOVERNED AT THE USER LEVEL
Each person signs in with their own identity, and sessions are visible to the team according to role.
GOVERNED AT THE ROLE LEVEL
A role decides what a person may see and do, and which actions need an approval gate.
GOVERNED AT THE DATA LEVEL
Classification decides which records and data levels may enter the mirror and the workspace.
Readiness and confirmation
Start when the inputs are owned, accessible, and testable.
Gate 1
Before Day 0- SOW signed by both parties
- NDA and Data Management Plan signed
- All owners named in the owner table
- Kickoff date set
Gate 2
Before the on-site week- Access granted for the listed systems
- Representative Operations examples prepared
- On-site dates and location confirmed in Zurich
- Friday review slot set in the calendar
Gate 3
Before production data- Data classification approved, including Restricted Data
- Access methods and credential handling approved
- Retention rules approved
- Model usage policy approved
Readiness item
Ready
Owner
Date
SOW signed by both parties
□
NDA and Data Management Plan signed
□
Executive sponsor and acceptance authority named
□
Access granted for the listed systems
□
Representative Operations examples prepared
□
On-site week dates and location confirmed
□
Friday review slot and escalation path set
□
| Confirmation | Name | Role | Signature | Date |
|---|
| KII | | | | |
| MIOSA LLC | Roberto H. Luna | Principal Architect and Engagement Lead | | |
Definition of ready: every critical input has a named owner, an approved access path, and a testable acceptance consequence.
