Skip to content
24/48h shipping across Italy
Home Documentation
Shop Blog Contact Us My account
Skip to content
Documentation navigation

GLPI capability evaluation for k0smos

Outcome

No GLPI-derived module is implemented yet. The ownership matrix is complete; real-user demand and source-of-truth interviews are still required. ADR 0008 prohibits cloning GLPI or creating a generic Asset schema before that gate. Scheduling is also explicit: GLPI is the final backlog evaluation and those interviews do not begin until every other accepted task is complete.

The comparison uses current official GLPI capability descriptions. GLPI covers hardware/software/network inventory, custom asset definitions, tickets, problems, changes, SLA, planning, licenses, suppliers, contracts, projects, knowledge, reservations, rules, notifications, reports and audit logs. These labels are capability inputs only; GLPI's schema and UI are not implementation templates for k0smos.

Capability and ownership matrix

Capability Existing k0smos owners Coverage and gap Candidate decision after interviews
Inventory / assets Ecommerce inventory, Kit, Storage, Media, Opcua, ModbusUi Product stock and industrial readings exist; no generic owned asset lifecycle, serial/model/location or physical inventory Native bounded Asset only if demand; otherwise GLPI sync
CMDB relationships / impact Client, Project, Ticket, Calendar, Deadline Stable business links exist; no typed arbitrary asset dependency/impact model. ADR 0003 rejected a graph DB for current shallow traversals Add bounded Asset relationships in SQL; integrate GLPI impact data when GLPI is authoritative
Incidents / requests Ticket, Client, Project, Notification Operational ticket lifecycle exists; no explicit GLPI-style incident/request classification and self-service form taxonomy Extend Ticket only for confirmed workflow semantics; do not create a parallel ticket module
Problems Ticket, Project, Documentation Tickets can record work, but no symptoms/cause/known-error aggregate across incidents Independent Problem increment or GLPI link after repeated incident evidence
Changes Project, Ticket, Calendar, ToDo, Deadline Planning primitives exist; no approval/test/review change lifecycle or risk/rollback contract Independent Change increment; reuse planning contracts, never encode it as a ticket status hack
SLA / OLA Ticket assistance contracts, Deadline, Calendar, Notification Contract hours and alerts exist; response/resolution clocks, pause calendars, OLA and escalation policies do not Extend Ticket/Deadline through a separate SLA increment after policy/process discovery
Planning Project, Calendar, ToDo, Deadline Strong native coverage for tasks, events, deadlines and recurring ticket work Retain native ownership; integrate only external references
Reservations Ecommerce inventory Checkout stock reservations exist; reservable equipment, availability calendars, hand-over and return do not Separate equipment-reservation increment only with Asset demand; never reuse commerce reservations semantically
Licenses / contracts / warranties Ticket assistance contracts, Deadline subscriptions, Finance, Media license metadata Partial contract/deadline/financial coverage; no asset/software entitlement, seat allocation or warranty lifecycle Treat licenses and warranties as later Asset-adjacent increments; reuse Deadline alerts
Suppliers Deadline supplier field, Finance/Ecommerce purchasing context, Client Supplier text/context exists; no authoritative supplier directory, evaluation or contract links Decide whether Client gains an organization role or Asset owns a supplier reference; avoid duplicate party records
Projects Project, ToDo, Calendar, Ticket, Deadline Native project recap, tasks, schedules and linked operations Retain native ownership; link external GLPI IDs only if integrating
Knowledge Documentation, Blog, Page, Media Reviewed public docs and content exist; no ticket-to-known-solution workflow or internal/public knowledge promotion policy Extend Documentation through an opt-in provider only after editorial/ACL requirements
Notifications Core Notification, mail, queue, OneUptimeApi Native in-app/email/preferences/operational channel and worker diagnostics Retain native ownership; translate imported GLPI events at integration boundary only
Audit / import audit log, DataExchange, Psapi, Wpapi, Esapi, Ecommerce provenance Strong package/import/provenance patterns; no GLPI connector or conflict policy Reuse DataExchange/provenance contracts for any connector; never copy GLPI tables

Product interview and ranking gate

Interview at least one representative from each role that exists in the target organization: requester, technician, service owner, asset/finance owner, and administrator. Record no credentials, personal data, serial numbers, or ticket content in the scorecard.

For every capability ask:

  1. What event starts the work and how often does it occur per week/month?
  2. What is done today, in which system, and who is authoritative for each field?
  3. What failure creates operational, financial, security, or compliance risk?
  4. Which links/reports/notifications are needed to complete the task?
  5. Is GLPI already deployed, and must k0smos read, write, or only link to it?
  6. What is the smallest end-to-end result that would replace manual work?

Score each gap from 0 to 5:

Dimension Meaning
Frequency How often the workflow occurs
Operational risk Impact of delay, error, loss or outage
Integration value Benefit of connecting existing k0smos owners
Confirmed users Breadth of distinct roles/teams needing it
Overlap penalty Existing coverage or risk of duplicate ownership

Priority score is frequency + operational risk + integration value + confirmed users - overlap penalty. A number is not automatic approval: record qualitative evidence, source-of-truth ownership, migration/integration constraints, and the decision owner. No implementation enters planning with only one uncorroborated interview.

Choice per confirmed gap

Native bounded implementation

Choose native only when k0smos workflows are authoritative and integration would add more operational risk. A first Asset increment is limited to:

  • typed asset classes and validated fields;
  • location, owner/custodian and lifecycle state;
  • typed, bounded relationships and attachments through Media;
  • append-only provenance/history;
  • stable Client and Ticket links through contracts;
  • tenant ACL, migrations, search and DataExchange only when their ownership is explicit.

Search, MCP, notification and module-link providers remain opt-in. SQL is the canonical store; ADR 0003's graph no-adoption decision still applies.

GLPI integration

Choose integration when GLPI already owns inventory or ITSM lifecycle. Define a single source of truth per field and preserve remote ID, entity, version/update time and provenance. Sync must be incremental, idempotent and retry-safe; conflicts go to quarantine/review. Never mirror arbitrary GLPI tables or expose remote data without k0smos tenant/ACL checks.

No action

Choose no action when frequency/risk is low, GLPI already satisfies users, or the feature would duplicate Project, Ticket, Calendar, Deadline, Documentation, Notification, Finance, Ecommerce or DataExchange ownership.

Deferred independent increments

SLA/escalation, Problem, Change, equipment reservations, discovery agents, software-license management, supplier evaluation and rich CMDB impact analysis each require their own domain model, threat model, migrations, permissions, integration contract and acceptance evidence. Approval of Asset does not approve any of them automatically.

Official sources