AI Formulation Recommendation Engine
Gen AI Use Cases
AI Formulation Recommendation Engine
Case Overview
Project Snapshot
Understanding the Business Challenges
Every successful solution starts with understanding the problems, constraints and opportunities that shaped the project.
The gap sat at the front door. When a new brief arrived, matching it against the accumulated library depended almost entirely on an individual specialist's recollection of past work. Everything downstream of intake was systematised; the first and most consequential step was not.
That dependence on memory made the process slow, inconsistent between people, and fundamentally unable to scale with volume. Two specialists could reach different conclusions on the same brief, and neither could easily show why. A brief that closely matched existing work might be treated as new development simply because nobody recalled the precedent.
2.1 Where the Constraint Bit
- Matching a brief against the library took hours to days and depended on individual recall.
- Two specialists could classify the same brief differently, with no systematic way to reconcile.
- Compatibility checking was manual and therefore inconsistently applied.
- Accumulated precedent was effectively inaccessible unless someone remembered it.
- The bottleneck worsened as brief volume grew.
Facing Similar Business Challenges?
Our experts can help you plan, build and deliver the right technology solution for your business.
What We Set Out To Achieve
The project was shaped around clear business goals, measurable outcomes and a practical path toward long-term growth.
Agreed with the client before development began, each expressed so that it could be measured rather than asserted.
| Objective | Definition of success |
| Make precedent searchable | Turn the formulation library into a queryable knowledge base |
| Classify effort consistently | Systematic EPD / REN / TT / NPD classification with confidence |
| Enforce the rulebook | Deterministic compatibility checking on every candidate |
| Explain every suggestion | Plain-language rationale with attribution to specific records |
| Integrate, not replace | Surface suggestions inside the existing portal workflow |
| Keep the specialist deciding | Advisory by design, with the human retaining judgement |
A Practical Solution Built For Long-Term Success
We transformed the identified challenges into a practical, scalable and sustainable technology solution designed around real business needs.
Capspedia delivered a serverless AI engine that plugs into the existing portal through a single governed API. For any incoming brief it retrieves the closest matching formulations from the client's own library, applies the digitised compatibility rulebook to each candidate, classifies the development effort required, and returns a scored recommendation with a plain-language rationale attributed to specific records.
Two design decisions define the system. Compatibility checking is deterministic, executed by a rules engine rather than a language model, because a missed conflict is not an acceptable failure mode. And the engine is advisory by construction: it surfaces evidence and reasoning to a specialist who remains the decision-maker.
How The Solution Was Structured
The solution was broken into focused components, allowing each part of the platform to work together while remaining scalable and maintainable.
| Component | Function |
| Knowledge base ingestion | Formulation library normalised, embedded, and indexed with category-aware metadata |
| Rulebook digitisation | Compatibility rules formalised with explicit severity, conditions, and exceptions |
| Retrieval service | Ranked candidate formulations by category, base, and active-ingredient overlap |
| Re-ranking | Category-aware filtering with active-overlap weighting alongside semantic similarity |
| Rules engine | Deterministic conflict detection with severity classification |
| Classification | EPD, REN, TT, or NPD with a confidence score |
| Reasoning layer | Bedrock-generated rationale citing the specific records it drew on |
| Governed API | Authenticated recommendation endpoint consumed by the existing portal |
| Audit trail | Immutable record of every request and response for traceability |
The System Design Behind The Delivery
A thoughtfully structured architecture connects the application, data, infrastructure and services into a reliable and scalable technology foundation.
The runtime request flow, end to end. Each step is a discrete, independently monitored component per the component standard in CAPS-AI-DTC-001.
- A brief is submitted through the existing portal's intake or lab-evaluation screen.
- API Gateway with Amazon Cognito authenticates and admits the request.
- A Lambda orchestrator runs the pipeline end to end: retrieval, then rules, then reasoning.
- Amazon Titan Embeddings vectorises the brief for semantic search.
- OpenSearch Serverless returns candidates, pre-filtered on category and base metadata.
- The re-ranking step reorders candidates weighing active-ingredient overlap alongside similarity.
- The deterministic rules engine checks each candidate for conflicts and assigns severity.
- Amazon Bedrock classifies the effort required and produces the rationale, constrained to retrieved records.
- DynamoDB logs the suggestion; the response returns to the portal and renders inline.
The architecture is serverless throughout and defined entirely as code. Every service is reached through private connectivity under least-privilege access, and no data-layer resource is routable from the internet.
Model Selection And Core Approach
The foundation model was selected based on the project's requirements, performance expectations, reliability and ability to support the overall solution architecture.
Model selection followed Capspedia's standard procedure (CAPS-AI-FMS-001): hard constraints applied as a screen first, then weighted scoring of the surviving candidates against criteria fixed before benchmarking began. Candidates were evaluated on identical inputs using a curated evaluation set built from the client's own material.
| Criterion | How it was assessed |
| Instruction adherence | Whether the model confined itself to retrieved records and refused where evidence was insufficient |
| Reasoning depth | Quality of classification judgement on worked briefs against expert assessment |
| Output quality | Rationale clarity assessed by the client's own specialists |
| Structured output | Reliability of schema-conformant responses for portal rendering |
| Latency | P95 measured end to end, since the suggestion renders inside an interactive screen |
| Unit cost | Modelled at forecast brief volume |
7.1 Selection Outcome
A Claude model on Amazon Bedrock was selected for classification and reasoning, with Amazon Titan Embeddings for vectorisation after benchmarking against the client's own library. Compatibility logic was deliberately kept out of the model entirely: rules execute deterministically, and the model explains their output rather than deciding it.
Tools & Technologies Behind This Project
A carefully selected technology stack was used to build a secure, scalable and high-performing solution aligned with the project's technical and business requirements.
| Service | Role in the solution |
| Amazon Bedrock | Foundation model access for classificationrationaleand safety guardrails |
| Amazon Titan Embeddings | Vectorisation of briefs and formulation records |
| Amazon OpenSearch Serverless | Semantic search across the formulation knowledge base |
| AWS Lambda | Orchestratorrules engineand API handlers |
| Amazon API Gateway | Governed recommendation API with rate limiting |
| Amazon Cognito | Authentication and authorisation for API access |
| Amazon DynamoDB | Immutable audit trail of every request and response |
| Amazon S3 | Versioned storage for the libraryrulebookand artefacts |
| Amazon CloudWatch | Dashboard7 alarmscustom metricsand alerting |
| AWS X-Ray | Distributed tracing for end-to-end request visibility |
| AWS CloudFormation | Infrastructure as code for reproducible deployment |
| GitHub Actions | CI/CD with federated authentication and automated testing |
What We Learned Along The Way
Every complex project brings valuable insights. The challenges encountered during delivery helped refine the approach, strengthen the solution and shape better decisions.
Recorded because the resolutions generalise. Each has been carried into Capspedia's practice pattern library and informs how the next comparable engagement is scoped.
Historical records are heterogeneous in ways nobody documents
Existing formulation records varied in structure, granularity, and naming across categories and historical periods, which made direct embedding unreliable. Schema normalisation with category-aware field mapping, ingredient standardisation against a controlled vocabulary, and multi-pass validation resolved it. Working closely with the client's specialists caught the edge cases that automated normalisation would have flattened, and that collaboration was worth more than any additional tooling.
Tacit expertise has to be interviewed out, not extracted
The compatibility rulebook as maintained carried nuanced severity levels, conditional incompatibilities, and concentration-dependent interactions that were understood in practice but never formally written down. Structured interviews formalised each rule with explicit severity, conditions, and exceptions, followed by validation cycles in which specialists reviewed engine output against known conflicts until coverage was confirmed complete. We now budget for this as a discrete workstream wherever a rulebook is being digitised.
Semantic similarity alone is not domain relevance
Initial retrieval matched on ingredient names without weighting category context or base compatibility, so results were semantically close but often irrelevant to the brief. Adding category-aware filtering, base-type metadata, and a re-ranking step weighing active-ingredient overlap lifted top-3 relevance from 68% to 84%. Domain structure has to be encoded into retrieval explicitly; it does not emerge from the embedding.
Built To Grow With The Business
The solution was designed to remain reliable under changing workloads while providing the flexibility required for future business growth.
| Layer | Design position |
| Compute | Fully serverless: Lambda across availability zones with no capacity to provision or lose |
| Retrieval | OpenSearch Serverless scaling automatically with library size and query volume |
| Model access | Managed Bedrock endpoints with retry, backoff, and defined fallback |
| Integration resilience | The portal degrades gracefully if the engine is unavailable, returning specialists to the prior manual path rather than blocking intake |
| State | DynamoDB with on-demand capacity for the audit trail |
| Storage | S3 versioning across library and rulebook, enabling restore to any prior state |
| Observability | X-Ray tracing across the full request path for rapid fault isolation |
| Degradation | Where retrieved evidence does not support a confident match, the engine returns no recommendation rather than a weak one |
Because the engine is stateless and serverless, brief volume scales without intervention. Library growth is absorbed by the index; adding rules to the deterministic engine requires no code change; and the same pattern extends to adjacent decision points in the portal without re-architecture.