Field notes, sorted by subject.
This is the Pexon engineering blog, organised by business area rather than by date. Each area hub collects posts on one subject: running open-weight models on hardware you control, rolling Claude out across an enterprise, and making SAP, MES and PLM data reachable for AI systems.
One subject, one place.
Most engineering blogs are a date-ordered pile. Ours is a tree: every post hangs off exactly one business area, and each area has a hub that collects everything written about it.
That is partly for readers — if you came here because you have to run models inside your own network, you should not have to scroll past six posts about SAP extraction to find the two that matter. It is also the honest structure for the subject. These areas do not overlap much in practice: the people fighting a permission model in SharePoint are rarely the same people negotiating GPU capacity.
What you will not find here: benchmark tables lifted from a vendor deck, customer names we have not been given permission to use, or a post that ends in a demo request. Where we cite a number, the source and its date are on the page.
Business areas we write about
- Claude Enterprise Field Notes — MCP, Access and RolloutField notes on deploying Claude across an organisation: access control, connecting internal systems over MCP, measuring real usage, and reviewing agent-written code.
- Data Engineering for AI — SAP, MES and PLM Field NotesPosts on the unglamorous half of enterprise AI: extraction from SAP, MES and PLM, masking, entitlements that survive retrieval, and schemas nobody documented.
- Self-Hosted LLM Guides — Field Notes on Private AIField notes on self-hosted inference: picking an open-weight model, sizing GPUs, serving them in production, and what an in-house AI stack costs to operate.
Common questions
Why is the blog sorted by business area instead of by date?
Because a reverse-chronological feed buries the useful posts within weeks. Sorting by area keeps everything written about one subject in a single place, which is how people actually read a technical blog and how answer engines resolve a topic to a source.
Who writes these posts?
The engineers who run the engagements, not a content agency. Posts a named engineer has agreed to sign carry that byline; the rest are published under the company rather than under an invented name. Anything we have not built ourselves is described as an approach, not as experience we already have.
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.