Initial MobilityOps build pack (docs, contracts, scaffold)

knowledge/procedures/01-vehicle-checkout.md

@@ -0,0 +1,21 @@
+---
+document_id: vehicle-checkout-procedure
+title: Vehicle checkout procedure
+version: "1.2"
+effective_date: 2026-06-01
+department: Rental Operations
+status: active
+---
+# Vehicle checkout procedure
+
+## 1. Required checks
+
+Before a vehicle leaves the site, the rental employee must confirm the active booking, customer identity, driving licence and required signed documents. The recorded starting odometer must not be lower than the vehicle's current canonical odometer.
+
+## 2. Vehicle condition
+
+Complete the checkout inspection, record fuel level and visible pre-existing damage, and confirm that no blocking maintenance or data-quality issue is open.
+
+## 3. Release
+
+Only a vehicle with an approved checkout inspection may be set to rented. When a critical discrepancy is found, keep the vehicle blocked and escalate to Operations.

knowledge/procedures/02-vehicle-return.md

@@ -0,0 +1,25 @@
+---
+document_id: vehicle-return-procedure
+title: Vehicle return procedure
+version: "2.0"
+effective_date: 2026-07-01
+department: Rental Operations
+status: active
+---
+# Vehicle return procedure
+
+## 1. Register the return
+
+Open the active booking and record the ending odometer, fuel level, cleanliness, visible damage, technical warnings and relevant notes.
+
+## 2. Validate the reading
+
+A submitted odometer below the previous canonical reading must never replace the canonical value. Register the inspection, create a data-quality issue and request human review.
+
+## 3. Determine next state
+
+Damage or a technical warning requires a blocked state. A reached service threshold requires maintenance. Otherwise the vehicle moves to cleaning before it can become available.
+
+## 4. Follow-up
+
+The return automation may create a cleaning or maintenance follow-up, but MobilityOps remains the source of truth for the vehicle state.

knowledge/procedures/03-damage-handling.md

@@ -0,0 +1,21 @@
+---
+document_id: damage-procedure
+title: Damage handling procedure
+version: "1.3"
+effective_date: 2026-06-15
+department: Operations
+status: active
+---
+# Damage handling procedure
+
+## 1. Immediate actions
+
+When a vehicle returns with visible or reported damage, mark damage in the return inspection, add a concise factual description and keep the vehicle blocked. Do not promise the customer a repair cost or liability decision.
+
+## 2. Evidence
+
+Record at least four photographs in the source inspection system: full affected side, close view, wider context and vehicle registration. MobilityOps may store only the evidence reference in this PoC.
+
+## 3. Escalation
+
+Create an Operations review before any new rental. A vehicle with unresolved damage may not be marked available even when a future booking exists.

knowledge/procedures/04-odometer-anomalies.md

@@ -0,0 +1,21 @@
+---
+document_id: odometer-anomaly-guideline
+title: Odometer anomaly guideline
+version: "1.1"
+effective_date: 2026-05-20
+department: Operations
+status: active
+---
+# Odometer anomaly guideline
+
+## 1. Lower reading
+
+If a new reading is lower than the canonical odometer, preserve the submitted reading as evidence but do not lower the canonical value. Check for digit transposition, incorrect vehicle selection or a source-system import error.
+
+## 2. Resolution
+
+An Operations Manager may resolve the issue after checking the original inspection. Correct only the erroneous inspection or source mapping; do not rewrite valid historical readings.
+
+## 3. Escalation threshold
+
+Any unexplained reduction or a single increase above 2,500 kilometres during one rental requires review.

knowledge/procedures/05-cleaning-checklist.md

@@ -0,0 +1,21 @@
+---
+document_id: cleaning-checklist
+title: Vehicle cleaning checklist
+version: "1.4"
+effective_date: 2026-06-10
+department: Fleet Preparation
+status: active
+---
+# Vehicle cleaning checklist
+
+## 1. Interior
+
+Remove waste, inspect upholstery, clean kitchen and sanitary surfaces, and confirm that the inventory checklist is complete.
+
+## 2. Exterior
+
+Inspect windows, lights, tyres and bodywork while cleaning. Report newly observed damage rather than silently completing the task.
+
+## 3. Completion
+
+Cleaning completion alone does not make a blocked or maintenance vehicle available. MobilityOps derives availability from all active restrictions.

knowledge/procedures/06-maintenance-escalation.md

@@ -0,0 +1,21 @@
+---
+document_id: maintenance-escalation
+title: Maintenance escalation procedure
+version: "1.1"
+effective_date: 2026-04-01
+department: Workshop
+status: active
+---
+# Maintenance escalation procedure
+
+## 1. Triggers
+
+Escalate when a technical warning is reported, the service threshold is reached, a safety-related defect is observed or an existing maintenance block remains unresolved.
+
+## 2. State
+
+Set or retain the maintenance state. A future booking does not override a maintenance restriction.
+
+## 3. Release
+
+Only an authorised maintenance completion record and the absence of other blocking issues permit the vehicle to proceed to cleaning or availability.

knowledge/procedures/07-customer-documents.md

@@ -0,0 +1,21 @@
+---
+document_id: customer-document-requirements
+title: Required customer documents
+version: "1.0"
+effective_date: 2026-07-01
+department: Rental Operations
+status: active
+---
+# Required customer documents
+
+## 1. Checkout requirements
+
+The customer identity and valid driving licence must be verified in the source process before checkout. Required contractual documents must be signed.
+
+## 2. Data minimisation
+
+MobilityOps records only completion status and source references for this PoC. It does not store identity-document images.
+
+## 3. Missing information
+
+A booking with incomplete required documents is not ready for checkout and must appear as an attention item.

knowledge/procedures/08-privacy.md

@@ -0,0 +1,21 @@
+---
+document_id: privacy-guideline
+title: Operational privacy guideline
+version: "1.0"
+effective_date: 2026-03-01
+department: Management
+status: active
+---
+# Operational privacy guideline
+
+## 1. Minimum access
+
+Employees may access only the customer and booking information required for their role. External AI tools receive no unrestricted customer dataset.
+
+## 2. Knowledge platform
+
+Do not ingest customer personal data, booking notes or identity documents into the procedure knowledge collection. The collection is limited to approved internal guidance.
+
+## 3. Logging
+
+Audit action metadata and source references, but avoid copying unnecessary personal data into technical logs.

knowledge/procedures/09-booking-conflicts.md

@@ -0,0 +1,21 @@
+---
+document_id: booking-conflict-procedure
+title: Booking conflict procedure
+version: "1.2"
+effective_date: 2026-06-20
+department: Operations
+status: active
+---
+# Booking conflict procedure
+
+## 1. Detection
+
+Two reserved or active bookings for the same vehicle may not overlap. Imported legacy conflicts must be flagged as data-quality issues.
+
+## 2. Resolution
+
+Operations reviews both bookings, confirms source-system ownership and reassigns or cancels one booking in the authoritative booking system. MobilityOps records the reviewed outcome.
+
+## 3. Safety
+
+Do not automatically cancel a customer booking based only on an inferred conflict.

knowledge/procedures/10-roles-and-escalation.md

@@ -0,0 +1,21 @@
+---
+document_id: roles-and-escalation
+title: Roles and escalation matrix
+version: "1.0"
+effective_date: 2026-06-01
+department: Management
+status: active
+---
+# Roles and escalation matrix
+
+## Rental Employee
+
+May view assigned operational records, complete checkout and return inspections, and consult procedures. May not merge customer records or reset the demo environment.
+
+## Operations Manager
+
+May review all attention and data-quality issues, merge confirmed duplicate customers, retry workflow delivery and reset the synthetic demo.
+
+## Service integrations
+
+n8n, RAGcore and ITWorx MCP Hub use separate scoped identities. Service identities do not inherit an interactive user role.