Method and stack
The recurring architectural patterns the studio ships.
Each engagement is shaped by the constraints it arrives with — the data, the tenancy, the regulator, the user population — and no two builds are identical. A small number of patterns do, however, recur often enough to be worth naming. The six sections below describe those patterns at the level of the underlying mechanism, together with the specific engagement in which each pattern has most recently shipped.
Tenant-bound language-model platform
A durable, maintained open-source chat platform — LibreChat, at present — is extended rather than reconstructed. The generic eighty per cent of such a platform (message routing, streaming, model adapters, conversation persistence) is inherited from the upstream project; the engagement-specific twenty per cent is authored above it. Deployment is held inside the client's tenancy, with single sign-on wired through the client's existing identity provider and authorisation driven by the client's existing group structure.
The pattern holds on the engineering side only when the upstream project is actively maintained and when the studio's extensions are packaged in a way that allows upstream updates to be merged without a rewrite.
Engagement anchor
Chat:R at Rud Pedersen Group — an extended LibreChat deployment serving approximately one thousand staff across three Azure environments, with Microsoft Entra single sign-on scoped to the firm's domain.
Read the case study →Model Context Protocol gateway
Where a language-model platform has to reach into a client's existing document estate, a small Node.js server implementing the Model Context Protocol is deployed alongside the main application. The gateway exposes a specifically scoped set of upstream tools — typically Microsoft Graph endpoints over a streamable HTTP transport — with credentials injected from a managed secret store rather than held in configuration. The gateway is containerised and deployed as a first-class component of the platform, not as a sidecar added after the fact.
Keeping the set of exposed tools deliberately small is the design decision that matters most. A gateway that surfaces every available endpoint becomes a liability under audit; a gateway that surfaces three tools, each with a named purpose, does not.
Engagement anchor
Chat:R SharePoint Model Context Protocol gateway — Node.js MCP server, Azure Key Vault secret injection, streamable HTTP transport, three Microsoft Graph tools surfaced by design.
Read the case study →Retrieval-augmented generation pipeline
Ingestion, chunking, embedding, hybrid retrieval combining dense and sparse signals, reranking, and an evaluation harness that the pipeline is measured against before it is extended. The tooling at each stage is chosen by the shape of the document mix — the size distribution, the proportion of scanned to native-text material, the presence of tables or figures — rather than by vendor preference. The pipeline is built to be extended incrementally, beginning from the single document type that justifies the initial engagement.
The evaluation harness is established at the beginning of the engagement, not at the end. Retrieval pipelines without an explicit evaluation against held-out queries are difficult to extend without regressing; pipelines with one are not.
Engagement anchor
Rud Pedersen internal knowledge system — a retrieval-augmented pipeline over the firm's research and briefings library, with hybrid retrieval and reranking tuned to the document mix. Engagement in preparation for publication.
See the work page →Computer-vision segmentation in a clinical research setting
A U-Net (or directly comparable architecture) is trained against held-out imagery in a clinical or biomedical research context, with classical baselines — thresholding, k-means, watershed, active-contour, region-growing — built and reported alongside the deep-learning result. Validation is reported against intersection-over-union and Dice coefficient as primary metrics, with precision, recall, and specificity reported alongside. Mixed-precision training, parameter counts, and inference-pipeline details are documented at a level that allows a research-group principal investigator to evaluate reproducibility.
Building and reporting classical baselines is the discipline that distinguishes the pattern from a portfolio-style computer-vision project. Research-group principal investigators tend to reject submissions that present a deep-learning result without one; the baselines are not optional.
Engagement anchor
UCL Royal Free Hospital cell-spheroid segmentation — U-Net in PyTorch with classical baselines, validation intersection-over-union of 0.968 and Dice coefficient of 0.983 on the held-out imagery.
See the background on /about →Interpretable predictive modelling
Gradient-boosted tree methods — XGBoost or LightGBM, in practice — are used where the setting demands that the model be inspected rather than only consulted. SHAP-based feature attribution is produced as a first-class deliverable alongside the predictions, with out-of-sample validation framed around residual behaviour rather than around a single aggregate metric. Input data is drawn from a mix of client-owned sources and public registers, with the joins between them documented and the outlier treatment stated explicitly.
The pattern applies where the explanation is part of the deliverable, typically in financial, clinical, or regulated operational settings. It is less suitable where a pure-performance objective justifies a less-interpretable architecture.
Engagement anchor
House-price predictive model over HM Land Registry, Energy Performance Certificate, and Office for National Statistics public-register data, with SHAP-based explanation over the fitted model and IsolationForest outlier treatment. Non-client research work; demonstrates the pattern outside a live engagement.
See the background on /about →Azure-first tenant deployment
Where the target tenancy is Microsoft, the deployment draws on a defined subset of Azure services: App Service, Virtual Machines, Container Instances, Storage, Key Vault, and AI Search are the set most often engaged. Infrastructure is authored as Bicep; continuous integration and deployment run through GitHub Actions with federated OpenID Connect authentication between the workflow and the tenant, rather than through long-lived secrets. Environments are separated at the subscription or resource-group level and provisioned through the same templates, so that staging and production diverge by configuration rather than by hand-applied edits.
The work described here is conducted at an architecturally literate level: the studio authors the templates, wires the pipelines, and operates the environments. Where an engagement calls for deep individual-contributor cloud-platform engineering beyond the shape of this pattern — network design at scale, multi-region resilience architecture, FinOps at the organisation level — the studio pairs with specialist cloud engineers with whom it has worked previously. The distinction is stated plainly because mis-stating it would be the expensive sort of error.
Engagement anchor
The Chat:R deployment runs across three Azure environments on the pattern above: Bicep-authored infrastructure, federated GitHub Actions pipelines, Microsoft Entra single sign-on, and a considered pivot from managed Kubernetes to virtual machines early in the engagement.
Read the infrastructure notes →