EuclidPRO.ai

1. Summary

EuclidPRO.ai is a modular, self-hosted platform that software companies run for their own customers, built on skeleton_foundation, an open-source multi-tenant base. Its first module, Geolocation, gives field teams a self-hosted map of Qatar with automatic routing, downloadable route reports, navigation and a field app for recording data and tracking. The Geolocation module is live and in use by an HSE team of 35 users across 350+ locations, and the Task and Approval modules are next.

What euclidpro offers

euclidpro builds custom software on one proven foundation, in three tiers:

1. Digital transformation: forms, spreadsheets and email chains become governed workflows, with the data in one place and every step recorded.
2. AI agents: agents that triage submissions, draft reports and answer questions about an organisation's own data. They act only within a person's role, and every action is audited.
3. Applied intelligence: risk prediction, anomaly detection and document understanding, trained on the client's data and delivered inside the tools people already use.

Delivery. Map how the work really flows, assemble the modules, roles, scoring rules and limits, then deliver under the client's own address, logo and colours, with records on euclidpro infrastructure or in a database and storage the client already owns. The public product site is live at euclidpro.ai.

2. Problem and context

Who has the problem. Operations teams that work across many sites, such as HSE teams that visit and inspect hundreds of locations, and the software companies that build tools for them.

What it costs them.

• Field teams need to plan visits, get to each location and record what they find. Assumption: without one tool, this is split across consumer map apps, spreadsheets and messaging, so route plans, visits and field records don't connect, and someone re-keys the results into reports.
• Assumption: regulated and government-facing organisations often can't send location and operational data to third-party cloud services, which rules out most hosted mapping and field-service products.
• Assumption: a software company that wants to serve these customers has to rebuild the same base (tenants, users and roles, audit, backups, operations) before it can ship a single product feature.

EuclidPRO.ai answers all three: one platform, deployable wherever the customer needs it, with each capability added as a module.

3. History

EuclidPRO.ai did not start as a mapping platform. It moved through three stages.

1. AI training and compliance content (2024). The first version was a generative AI platform built for a 9,000+ multilingual shift workforce. It turned minimal inputs into complete training content and downloadable PDF presentations. It used multi-stage orchestration across course, module, slide, interaction and assessment planning, with mandatory human approval at every phase. It ran on Google Vertex AI and Gemini and was deployed on a Linux VDS.
2. Compliance and contracts. The product widened from training content to compliance and contracts management.
3. Modular platform (2026). EuclidPRO.ai was rebuilt as a modular, self-hosted platform on skeleton_foundation. Field Operations (Geolocation) is the first module.

Assumption: the pivot happened because every customer need (training, compliance, contracts, field work) depended on the same base of tenants, users, permissions, audit and backups. Building that base once and shipping each need as a module is faster and safer than building separate products.

The earlier version's roadmap covered learner records and dashboards, document intelligence (OCR, RAG, enterprise search) and policy and SOP workflow modules. That roadmap was superseded by the pivot. Current stage: the Field Operations (Geolocation) module is live and in use, and the Task and Approval modules are next.

4. Users and personas

The module is live and in use by an HSE team: 35 users across 350+ locations. Assumption: most of those users are field officers, with a small number of team leads.

5. Goals and non-goals

Goals

• Give field teams one self-hosted tool for routing, navigation and field data capture.
• Keep map and field data on infrastructure the customer chooses.
• Ship new capabilities as modules, without touching the security code.
• Prove the Field Operations module with its first users before building Task and Approval.

Non-goals

• A consumer navigation app or global map coverage. The map covers Qatar.
• Assumption: replacing customers' HR, ERP or document systems.
• Assumption: a public self-serve sign-up. Tenants are created by an operator.

6. Requirements

Functional requirements: Field Operations (Geolocation)

G-0. Next visit. As a field officer, I want the system to decide which site I visit next, so that no site is forgotten.

• Never-visited sites come first, then the site with the longest time since a visit.
• Ties are broken by risk band and distance from base.

G-1. Routing. As a planner, I want routes calculated automatically, so that I don't plan visits by hand.

• Outward and return routes run on the road network from each site's base.
• The round trip is credited when the visit is completed, then frozen.
• No third-party map or routing calls.

G-2. Reports. As a team lead, I want coverage and distance reporting, so that I can see what was covered and by whom.

• Coverage and risk mix per base.
• Distance reports per inspector, exported to CSV.
• A one-click site report card.

G-3. Field app. As a field officer, I want a field app that works on my phone.

• The field app installs to the home screen.
• Inspectors can see the sites closest to them.

G-4. Field data recording. As a field officer, I want to record data at a site, so that what I find is captured once, on site.

• Every form autosaves on the device and sends itself when the network returns.
• Records are visible only inside the officer's own organisation.

G-5. Tracking. As a team lead, I want to see where my field team is, so that I can coordinate visits.

• Tracking positions are visible only to roles allowed to see them.
• Tracking data is stored in the tenant's own schema.

G-6. Risk scoring. As an administrator, I want sites scored for risk in a way I can control and audit.

• Sites are scored by an audited model.
• Weights, thresholds and override rules are edited visually, tested in a what-if simulator and published as audited versions.

G-7. Import. As an administrator, I want to load our sites in bulk.

• Sites are imported from CSV or GeoJSON.
• Columns map themselves, and every row is previewed on a map before saving.

G-8. Map. As anyone using the module, I want to see every site at a glance.

• Every site is on a self-hosted map, coloured by risk and by how long since anyone looked.

Functional requirements: platform

P-1. Modules per tenant. As an operator, I want to switch modules on per tenant or plan.

• A module is off by default. When it is off, its routes and screens are not available to that tenant.

P-2. Tenant administration. As a tenant administrator, I want to manage users, roles, departments and groups in my own workspace.

P-3. Deployment choice. As a customer IT lead, I want to run the platform as SaaS, in a private cloud, on-premise, air-gapped or in Docker.

P-4. Operator console. As an operator, I want to bring organisations online and control what they can use.

• Guided onboarding for new organisations, and plans.
• Capabilities switched on or off per plan or organisation in seconds.
• Every change is versioned and audited.
• Organisations' own admins can change the settings marked as theirs.

P-5. Organisations. As an organisation, I want the platform to look and behave like ours.

• Own address, logo and colours.
• Records kept apart from other organisations.
• Roles defined by each organisation; access follows role.
• Invitations, and delegation that expires on its own.

P-6. Individuals. As a person outside an organisation, I want my own account, with a plan, personal projects and shared groups.

P-7. Security. As a client, I want the platform's security and service levels to be explicit.

• Access is checked on every request.
• Bring-your-own database and storage, verified before use.
• An administrative record that can't be edited afterwards.
• Passkeys for administrators, extra checks before sensitive actions and protection against automated attempts.
• Encrypted backups and tested restores.
• Availability, response times and backup schedules agreed per client in an SLA.

Non-functional requirements

7. Solution overview and architecture

EuclidPRO.ai is skeleton_foundation plus product modules. The foundation provides tenants, sign-in, roles, audit, files, backups and operations. Each module adds its own tables, API routes and screens, and declares its tenant tables in one manifest.

Deployment options: SaaS, private cloud, on-premise, air-gapped and Docker.

8. AI design

Routing and navigation are deterministic. Site risk scoring uses an audited model with versioned, simulator-tested rules. The AI agents tier works only within a user's role, and every agent action is audited.

How models are chosen. Models and infrastructure are evaluated on accuracy, latency, cost, privacy, security and scalability. The method combines:

• schema validation of structured outputs;
• latency and time-to-first-token (TTFT) measurement;
• normalisation of outputs before comparison;
• failure analysis;
• LLM-as-judge scoring;
• review by subject-matter experts (SMEs).

Human in the loop. Human approval stays in the loop before anything is published. In the earlier version, every orchestration phase (course, module, slide, interaction, assessment) had a mandatory approval gate.

Failure handling. Outputs that fail schema validation are not used. Assumption: they are regenerated or sent back to the reviewer, and nothing reaches publication without approval.

Earlier version's models. Google Vertex AI and Gemini, for structured generation, evaluated against hallucination risk and output-quality rubrics.

9. Success metrics

Confirmed

• Live, in use by an HSE team: 35 users, 350+ locations.
• Public product site live at euclidpro.ai.

Metrics to track

• Weekly active field users
• Locations visited per week, and share of planned visits completed
• Time to plan a route, compared with the previous method
• Share of visits with a complete field record
• Route reports downloaded
• Tracking coverage during working hours
• Platform uptime
• Backup restore drill pass rate
• Time to provision a new tenant

10. Release history and roadmap

Assumption: Task ships before Approval.

11. Risks and open questions

Risks

• One customer team. The current usage evidence comes from a single customer team. Mitigation: collect the metrics above and agree success criteria with the next clients.
• Location privacy. Tracking people is sensitive. Mitigation: role-based visibility, tenant isolation and a clear tracking policy agreed with each customer.
• Map data freshness. Assumption: self-hosted map data must be updated by the operator, so roads and locations can go out of date.
• Small team. A team of three carries the platform and the modules.
• Air-gapped updates. Upgrading installations without internet access needs a tested offline procedure.

Open questions

• How often is the map data refreshed?
• Which module comes after Approval?

12. My role

• Head of AI, Product and Technology at Secura Eyes Informatics: product discovery, strategy, roadmap, UI/UX, architecture, full-stack development, deployment and go-to-market.
• Architected EuclidPRO.ai and built the first version solo.
• Wrote skeleton_foundation, the open-source base the platform runs on.
• Now lead a team of three: a full-stack developer, a cybersecurity specialist and a software engineer.
• Evaluated AI models and infrastructure and defined the human-oversight and responsible-AI controls.
• Own product positioning, commercial models, pricing, partnerships and market-entry plans, and advise leadership on technical trade-offs.