Technology stack and execution model

The stack is deliberately conservative. Components are widely adopted, well understood by enterprise IT teams, and capable of supporting secure, scalable, and auditable delivery over time.

This section also explains how AI execution is constrained and controlled within the platform. Rather than relying on open-ended or autonomous behaviour, Spero-ai uses structured, rule-driven execution models that align with governance and risk requirements.

Technology selection and execution patterns are designed to support long-term maintainability and do not depend on a single vendor or model.

Technology stack and rationale

Spero-ai uses a deliberately conservative, enterprise-grade technology stack. Components have been selected based on maturity, operational predictability, and alignment with government security and data-sovereignty expectations rather than novelty.

The technologies used are widely deployed in regulated environments and are intended to be understandable, supportable, and reviewable by internal IT teams.

Frontend and core application services

Next.js — User interface layer

Next.js is used to deliver the web-based user interface.

It was selected because it:

• Supports fast, responsive interfaces across devices and browsers

• Performs well in low-bandwidth or constrained environments through server-side rendering

• Aligns with accessibility requirements, including WCAG standards

The frontend is stateless and does not hold authoritative data or decision logic.

Spring Boot + Netty — Core application services

Spring Boot is used for core backend services, with Netty providing high-performance, asynchronous request handling.

This combination was selected because it:

• Is widely used and well understood in government and enterprise systems

• Provides mature security, authentication, and encryption libraries

• Supports clear service boundaries and long-term maintainability

The backend enforces workflow rules, permissions, and validation independently of AI services.

Data and event processing

PostgreSQL + pgvector — Data storage and retrieval

PostgreSQL is used as the primary data store.

It was selected because it:

• Provides ACID-compliant transactions suitable for records and audit requirements

• Scales reliably for structured and semi-structured data

• Supports advanced retrieval through pgvector for semantic search and citation linking

Data remains under client ownership and is encrypted at rest and in transit.

RabbitMQ — Event and workflow coordination

RabbitMQ is used to manage asynchronous processing and event-driven workflows.

It was selected because it:

• Decouples background processing from user-facing services

• Improves resilience by preventing cascading failures

• Supports horizontal scaling without complex orchestration

This ensures that workload spikes do not degrade core system responsiveness.

AI processing and sovereign inference

Python + OCR — Document understanding

Python-based services are used for document processing, OCR, and AI-assisted analysis.

This approach:

• Enables extraction of structured data from PDFs and scanned documents

• Integrates directly with assessment and compliance workflows

• Reduces manual data entry without bypassing review controls

AI outputs are treated as draft artefacts and remain subject to human review.

Ollama/vLLM/ TGI — Controlled AI inference

AI inference services are deployed using infrastructure that supports on-premise and private execution.

This allows:

• AI models to run entirely within client-controlled environments

• No external data sharing or dependency on public AI services

• Model vetting, versioning, and approval within organisational governance

Inference infrastructure can scale from small pilots to production deployments without changing architectural patterns.

Controlled AI execution model

Spero-ai is designed to use large language models in a constrained and predictable way. Rather than relying on open-ended prompting or autonomous agent behaviour, the platform limits AI degrees of freedom through structure, rules, and step-based execution.

This approach is intended to prevent hallucination, inconsistency, and uncontrolled variation in regulated workflows.

Risks of open-ended AI in enterprise processes

Large language models are probabilistic systems. When asked to interpret open-ended instructions or perform multiple tasks simultaneously, they will attempt to optimise outputs, often introducing unintended changes in structure, logic, or compliance.

In regulated environments such as planning, permitting, and assessment, this behaviour is not acceptable.

Outputs must remain consistent with:

• Defined workflows

• Jurisdictional rules

• Fixed document formats

• Evidentiary and audit requirements

Spero-ai is explicitly designed to prevent AI systems from inventing process, structure, or interpretation.

Output-first and rule-based control

Before any AI execution occurs, Spero-ai defines the permitted output space.

This includes:

• Fixed output structures (forms, cards, reports)

• Allowed layouts and components

• Permitted response types (e.g. classification, extraction, validation, summarisation)

Once structure is fixed, authoritative rule sets are applied. These include planning rules, jurisdictional constraints, validation logic, and controlled terminology.

AI operates within these boundaries and cannot override or bypass them.

Step-based execution and validation

AI tasks within Spero-ai are executed as small, sequential steps rather than a single, open-ended prompt.

Each step:

• Has a narrow, defined scope

• Is context-aware of prior steps

• Is validated against rules before proceeding

Discarded approaches are not silently reintroduced, and outputs are checked before advancing. This prevents uncontrolled course correction and supports traceability and audit.

Human involvement is positioned upstream — in defining structure, rules, and approvals — rather than correcting AI output after the fact.