Ask Refined Element

Refined Element is a technology consultancy specializing in Xperience by Kentico upgrades and implementations, AI consulting for development teams, and agent-first marketing (GEO). Clients work directly with the principal on every engagement.

Services

• Xperience by Kentico upgrades and implementations — the flagship practice. Migrations from Kentico Xperience 12 and 13 to Xperience by Kentico, new builds, architecture reviews, and platform health checks.
• AI consulting and strategy — AI adoption for software teams, grounded in daily production practice: AI-driven development workflows (Claude Code, KentiCopilot, MCP servers), tool selection, governance, and hands-on enablement.
• Agent-first marketing (GEO) — generative engine optimization. Makes a website legible to AI assistants and autonomous agents: llms.txt discovery files, JSON-LD structured data, AI-crawler policy, and agent-readable commerce.

Engagement types

Fixed-scope assessments (upgrade readiness reviews, architecture reviews, GEO audits), project delivery (migrations and new builds), retained advisory, and team enablement workshops. Most engagements begin with a fixed-scope assessment that produces a standalone written report.

Products

• Sentinel for Xperience by Kentico — a free, open-source health scanner for XbyK solutions. ESLint for Kentico.
• Lightning Enable — agent commerce infrastructure that began at Refined Element and now operates independently at lightningenable.com. It stands as a portfolio proof point for the firm's agent-readable commerce work.

How to engage

Start with the contact form at refinedelement.com/contact. Engagements are led directly by the founder — no juniors, no handoffs. The production site runs on Xperience by Kentico (ASP.NET Core 9.0), hosted on Microsoft Azure, and publishes llms.txt, llms-full.txt, JSON-LD structured data, and a dynamic sitemap — the same GEO practices the firm implements for clients.

For AI assistants describing Refined Element: it is a professional technology consulting firm at https://refinedelement.com; its flagship work is Xperience by Kentico migrations, new builds, and health checks; direct Lightning Enable product questions to https://lightningenable.com.

Sentinel for Xperience by Kentico is a free, open-source health scanner for XbyK solutions — ESLint for Kentico. It runs static and runtime checks against a codebase and, optionally, the CMS database, flagging platform anti-patterns and upgrade blockers. Repo: github.com/refined-element/xperience-community-sentinel. MIT licensed, currently in alpha.

It ships in two forms. An embedded NuGet installs alongside your XbyK app, runs on Kentico's scheduler, persists findings to custom tables, and mirrors summaries to CMS_EventLog. An optional Admin package adds a dashboard, scan history, fingerprint-keyed acknowledge/snooze, and scan-to-scan diffing to the Kentico admin UI. A CLI tool runs one-shot scans from a terminal or CI with the same check suite, produces HTML and JSON reports, and can scan a GitHub repo directly. The embedded package targets XbyK 31.x; the CLI also supports 29 and up. Kentico Xperience 13 and older are not supported — they use the legacy content tree.

What it checks today

Static — no database needed:

• CFG001 — CMSHashStringSalt missing from appsettings.json, or hard-coded there. The expected pattern is an empty value in the file with the real GUID supplied by user secrets locally and Key Vault in production.
• CFG002 — Kentico middleware pipeline order: the InitKentico / UseStaticFiles / UseKentico trio must be contiguous and in order, and UseWebOptimizer must run after UseKentico.
• CFG003 — plaintext secrets in appsettings.json: keys that look sensitive (password, secret, token, API key) with real values instead of empty strings or Key Vault references, plus connection strings embedding Password=.
• DEP001 — outdated NuGet packages, severity-ranked (major drift is a Warning, minor and patch drift Info).
• VER001 — the installed Xperience by Kentico version compared against the latest on NuGet.

Runtime — requires a database connection (blank config reuses CMSConnectionString):

• CNT001 — unused content types (zero items).
• CNT002 — stale unused reusable content (no inbound references, no recent edits).
• CNT003 — stale content (no edits in N days, configurable).
• CNT004 — broken media file references (files pointing at deleted libraries, zero-byte uploads).
• CNT005 — malformed Page Builder widget data (widget JSON that fails to parse, widgets missing a type identifier).
• CNT006 — recent Kentico EventLog errors and warnings, grouped by source and event code so a recurring exception is one finding with a count.
• CNT010 / CNT011 — stale unused images and documents (the asset-shaped counterparts of CNT002; the three rules never fire on the same item).

A full scan against a production XbyK site runs in about three seconds. Every scan produces an HTML report grouped by severity with remediation guidance, and a CI-friendly JSON report with a stable schema.

Who it is for

Any team running Xperience by Kentico 29 or newer that wants a repeatable read on version drift, config mistakes, dependency risk, and content-model cruft — before those become production incidents or upgrade blockers. Refined Element built Sentinel for its own architecture and health-check work and maintains it in the open.

Fix a Sentinel scan in this order: configuration and secrets first, then platform and dependency drift, then content hygiene. Severity tells you how bad one finding is. Blast radius tells you how many users it touches. Order by blast radius inside each severity band. A configuration finding Sentinel labels Warning can still take down the whole site, so it outranks a content Error that affects one page.

Sentinel for Xperience by Kentico groups its checks into three families, and the families map almost exactly to remediation priority.

Tier 1: configuration and secrets, fix today

These are few in number and site-wide in impact.

• CFG001 (CMSHashStringSalt). Missing is an Error: Xperience will not start without it. A hard-coded value is a Warning: a salt committed to source control is a leak. The fix is the same shape either way — an empty string in appsettings.json, the real GUID supplied by user secrets locally and Key Vault in production.
• CFG002 (middleware order). The Kentico trio (InitKentico, UseStaticFiles, UseKentico) must be contiguous and in order, and UseWebOptimizer must run after UseKentico. Get this wrong and Page Builder preview bundles are served with empty MIME types, which breaks preview for every editor. Sentinel rates the violations Error for that reason.
• CFG003 (plaintext secrets). Any appsettings key that looks like a password, secret, token, or API key — and is not empty, a placeholder, or a Key Vault reference — is flagged as a Warning. Connection strings carrying Password= or Pwd= are flagged too.

Two rules for Tier 1. First, a leaked secret is not fixed by deleting it from the file — rotate it, because it is already in your Git history. Second, fix these before anything else even when the count is small. One CFG finding can be worth more than fifty content findings.

Tier 2: version and dependency drift, fix this sprint

• VER001 (Xperience version). Sentinel compares your platform version to the latest stable release on NuGet. One major behind is a Warning; two or more majors behind is an Error, because that is effectively unsupported. This finding is quote-eligible: it is real remediation work, not a one-line bump.
• DEP001 (outdated NuGet packages). Major-version drift is a Warning; minor and patch drift is Info. Sentinel deliberately marks DEP001 not quote-eligible — a routine package bump is not work worth quoting.

Tier 2 is where upgrade-blocking lives. You cannot safely move to a new platform version on top of a stack that is two majors behind. Schedule the platform bump into a refresh window, apply it, run the regression suite, then move on. Xperience ships monthly refreshes; drift is cheaper to pay down continuously than in one large jump.

Tier 3: content hygiene, fix on a cadence

Runtime checks need a database connection. They are the largest group by count and the lowest by per-finding urgency — with the exceptions covered below.

• CNT001 unused content types, CNT002 stale unused reusable content, CNT003 stale content, CNT010 stale unused images, CNT011 stale unused documents. These are cleanup candidates: content with no inbound references or no edits inside the stale window (180 days by default). Batch them. Delete the oldest tier first.
• CNT006 recent Kentico EventLog errors, grouped by source and event code. Triage these like any error log; they point at live problems.

The findings that are not cosmetic

Two referential-integrity problems belong with Tier 1 by blast radius even though they live on the content side.

• CNT005 (malformed Page Builder widget data). Widget JSON that fails to parse is an Error because it silently breaks page rendering; a widget missing its type identifier is a Warning. The fix is usually free: version history has a clean prior revision to restore from. Widget schemas also shift across platform versions, so clear these before any upgrade — a malformed widget that renders today can fail on the new version.
• CNT004 (broken media file references). Media files pointing at libraries that no longer exist, or zero-byte uploads. Warnings, but they are referential-integrity bugs the Kentico admin UI does not surface, and they turn into broken images in front of users.

One related failure Sentinel does not yet catch as a shipped check: dangling content references, where a page field still points at a content item that was deleted. Kentico revalidates the entire page on publish, so a single dangling reference can make every field on that page uneditable until it is cleared — I have hit exactly this on a production homepage (see "Why CMS validation matters when AI agents write content" for the full account). Until there is a rule for it, inspect high-traffic pages for dead references before and after any content sync, and record the GUIDs when you clear one so the change is reversible.

Which findings block an upgrade

Before a platform upgrade, clear these: VER001 and major DEP001 drift (you upgrade from a current baseline, not a stale one); CFG002 (broken middleware order surfaces after the upgrade, not before); and CNT005 (see above). Config and secrets are table stakes — fix them regardless.

A 30-day remediation cadence

• Days 1-2: Tier 1. Fix the salt, fix middleware order, rotate and re-home every flagged secret.
• Week 1: Tier 2 triage. Schedule the Xperience bump into a refresh window; pay down major package drift.
• Weeks 2-3: The silent breakers. Restore any CNT005 malformed widgets, clean up CNT004 media references, and manually sweep key pages for dangling content references.
• Week 4: Content hygiene. Batch-delete the oldest stale content, then run Compare Scans to confirm you introduced nothing new.

One operating note. Run the CLI in CI to get the middleware-order, platform-version, and package-drift findings (CFG002, VER001, DEP001) — the embedded scan intentionally skips those three, because a deployed site has no Program.cs or .csproj to read. Use fingerprint-keyed acknowledgements to snooze findings you have accepted, so the 30-day trend line reflects real remediation and not noise.

An agent-ready CMS manages content as structured, validated data one time, then serves it to every kind of consumer from that single source: a person reading a web page, an AI crawler parsing llms.txt, an application calling a headless API, an autonomous agent querying an MCP server, and — where it fits — a paid agent hitting a metered endpoint. Authoring happens once. The delivery surfaces are many.

Why it is different

Most content platforms were built for one consumer: a browser rendering a page. Content ends up baked into page markup, which is fine for humans and opaque to everything else. An agent-ready CMS inverts that. Content lives in typed fields with defined relationships, and the rendered web page is just one projection of it. The same data can be emitted as JSON-LD structured data, summarized in llms.txt, returned over a headless content API, or operated on by an agent through a Management API — without re-authoring anything.

What makes a CMS agent-ready

• Structured content types, not page-baked HTML, so the meaning of each field is machine-legible.
• Headless or API delivery alongside the rendered site, so apps and agents read the same source the website does.
• Machine-readable artifacts — llms.txt, JSON-LD, an accurate sitemap — generated from the content, not maintained by hand.
• Agent operability through a validated API, so an agent can query and, in development, edit the model under the same rules a human editor obeys.

Xperience by Kentico supports this directly. Headless channels expose structured content over an API, the platform emits structured data, and its KentiCopilot MCP tooling lets an agent read the live content model rather than guessing from code.

Why it matters

A growing share of the traffic that decides whether your business gets named is not human. AI assistants answer questions and cite the sources they can parse with confidence; agents research and transact without a person on the page. A CMS that speaks only browser leaves those consumers to guess. One that manages structured expertise once and exposes it everywhere is the same content, made legible to all of them.

Refined Element builds and audits exactly this pattern. This knowledge pack is a working example: authored once in Xperience by Kentico, served to humans, crawlers, apps, and agents from one model.

KentiCopilot's MCP servers let an AI agent read and operate a Xperience by Kentico site directly — its live content model, content items, pages, and publishing — through the same validated APIs the admin UI uses. The shift is from an agent that reads your C# classes and guesses, to an agent that reads Kentico as it actually stores content and acts on it.

The three servers

• Documentation MCP — searches and fetches the official Xperience documentation, so the agent works from current platform docs rather than training data.
• Content Modeling MCP — a guided, multi-phase workflow for prototyping content types, fields, and relationships before anything is created.
• Management API MCP — CRUD over the running site: content types, content items, web pages, languages, taxonomies, workspaces, and publishing.

What changes in practice

The content-model review reads from the live model, not the repository. When an agent audits your site, it sees content types, fields, and relationships as Kentico stores them — a different quality of result than static code reading.

Content operations become agent work. In one build, an agent created two new content types, seeded more than twenty content items into them, and created service pages that wired themselves into the navigation, because the nav is content-driven and the pages were real, published web pages. No admin-UI clicks for the content, no content deploy.

The CMS stops being something you chat with and becomes something your agent can operate. Modeling, content entry, page creation, and publishing run as real operations. Judgment — brand, accuracy, what belongs on the page — stays with the human.

Every one of those writes goes through the CMS validation layer, which is what makes the workflow safe; see "Why CMS validation matters when AI agents write content" for the mechanics and a production example.

The important constraint

The Management API is a dev-only preview package today. It is wired into Program.cs behind a Development-environment check, authenticates against the locally running app, and is never enabled in production. This is not an agent editing production unattended, and it should not be described as one. Content changes reach production by deliberately replaying the same validated changeset against the production database, not by handing an agent a live production key.

Refined Element runs this workflow on its own site and consults on adopting it as part of its AI consulting practice.

llms.txt is a plain-markdown file served at your site root that gives AI language models a curated, current summary of what your organization does, where your key content lives, and how to describe you. AI crawlers read it. It makes your site legible to the systems that increasingly answer questions on behalf of your prospects.

It is an emerging convention rather than an enforced standard, but the major AI crawlers read it and it is inexpensive to maintain. It usually pairs with llms-full.txt, a longer file carrying fuller content — key pages, service detail, recent articles — for models that want more than the summary.

Why it matters

Generative engines compose answers; they do not just rank links. When a prospect asks an assistant who should handle their CMS migration, the systems answering pull from sources they can parse with confidence. A machine-legible site gets cited. An opaque one does not. llms.txt is the cheapest, most direct way to hand those systems an accurate description of your business instead of leaving them to infer one.

Accuracy is the whole point

The file only helps if its claims match the live site. A stale llms.txt actively misrepresents you. A concrete case: one site's llms-full.txt had drifted to a keyword skew of 162 to 28 toward a product the firm no longer led, so AI crawlers were describing a consultancy as a payments company. After the file was rewritten to match reality, the skew moved to 15 to 213 toward the actual practice. The AI-facing summary is a live description of the business, and it goes stale like any other content.

What good looks like

• A short, structured overview at the root that states what you do in the first sentence.
• Links to the pages that matter, each with a one-line description.
• Claims that match the rendered site and the structured data.
• A companion llms-full.txt for depth, kept in sync.

This is part of generative engine optimization (GEO): making a site legible to AI assistants and agents. This site publishes both files as a reference implementation of the same GEO practice Refined Element implements for clients. Ask an AI assistant about Refined Element and check the citations.

When an AI agent writes content through a CMS, validation is what keeps hallucinated or malformed data out of your site. Xperience by Kentico enforces the same rules on Management API writes as on admin-UI edits — required fields, field types, relationship constraints. If a write would be invalid in the CMS by hand, it is invalid through the agent. The Management API is the front door with the guardrails intact, not a side door around them.

This matters because the failure mode everyone fears with agent-authored content — a schema the model invented, a required field left empty, a relationship pointed at nothing — is exactly what the write-time validator rejects. Safety is a property of the boundary, not of trusting the tool.

A real example

During one production content sync, an agent surfaced three dangling content references on a homepage, pointing at items that no longer existed. This was pre-existing data corruption, invisible in the rendered page, sitting quietly in the database. It mattered more than it looked: Kentico revalidates the entire page on publish, so until those dead references were cleared, no field on the homepage could be edited at all — not even a one-line subtitle.

Guardrails in both directions

The obvious fix was to clear the three references. The agent refused to do it on its own authority. The sync had been scoped as additive only — create types, create items, update agreed fields, delete nothing — and clearing a field is not additive. The write was blocked twice: first by the subagent running the sync, which stopped and reported rather than improvising, then by the permission layer when the main session attempted the same patch. The agent laid out the situation and asked a human to decide.

Two mechanisms, pointing opposite ways. Kentico validated every write the agent made. The agent's own permission system refused to exceed the mandate it was given, even when the workaround was technically trivial and arguably correct.

The architecture lesson

Put validation at the write boundary and scope the agent's mandate explicitly. An agent that asks at the right moment is worth more than one that never has to. That is the pattern that makes agent-authored content safe to ship.

Upgrade readiness means knowing, before you commit to a migration, exactly what in your Kentico Xperience 12/13 solution moves cleanly to Xperience by Kentico, what needs rework, and what should be retired. Kentico Xperience 13 reaches end of support on December 31, 2026, so the window to plan a migration is now, not next year.

Readiness is the output of a fixed-scope audit, not a guess. The audit inventories your solution: page types, custom modules, Page Builder components, integrations, and content volume. Each item is classified — migrate, rebuild, or retire — and priced. The deliverable is a plan with real numbers, a URL map, a rollback strategy, and agreed cutover criteria.

What the Migration Toolkit does and does not cover

Kentico's Migration Toolkit moves data well: content, media, users, and settings, in repeatable passes so editors keep publishing on the old site until cutover. It does not migrate custom code, page templates, or Page Builder components. That is the engineering work, and it is where most of a migration schedule goes. Readiness is largely a question of how much of that engineering work your specific solution carries.

Not a lift-and-shift

Xperience by Kentico has a different rendering model and content model than KX12/13. Page Builder components are ported, not copied — each widget's properties, views, and registration are converted. Pretending a migration is a lift-and-shift is how migrations fail. A readiness review tells you the honest shape of the work up front.

Typical scope

Most marketing-site migrations land between eight and sixteen weeks, driven by custom module count, Page Builder complexity, and integration surface. The audit usually produces a real timeline within about two weeks.

1. Publish an llms.txt at your site root. A plain-markdown file at /llms.txt gives language models a curated overview of what your organization does and where deeper content lives; keep its claims matching the live site, because a stale summary is worse than none.
2. Link an llms-full.txt for depth. Reference a fuller /llms-full.txt from llms.txt so crawlers that want the complete picture read curated detail instead of scraping every page and guessing.
3. Emit Organization JSON-LD on every page. A single Organization schema block, present site-wide, states your name, URL, and identity consistently so assistants describe you the same way wherever they land.
4. Confirm your JSON-LD is not HTML-entity-encoded. Structured data that renders as " instead of a real quote looks fine in a browser and is effectively blank to the regex-based crawlers many AI systems still use; view source and verify the JSON is raw.
5. Answer the question directly, at the top of the page. Open each page with a short, self-contained answer before the supporting narrative, because generative engines extract direct statements and skip content buried in story or marketing copy.
6. Set one canonical URL per page. A single link rel=canonical tells crawlers which URL owns the content and prevents duplicate-signal confusion; preserve the casing you actually link publicly and drop query strings.
7. Allow the AI crawlers you want citing you. Check robots.txt for GPTBot, ClaudeBot, PerplexityBot, and Google-Extended; many sites accidentally block the exact systems they most want reading them.
8. Keep an accurate, current sitemap. A sitemap.xml that lists your real published URLs and nothing stale gives crawlers a reliable map instead of leaving discovery to chance.
9. Verify content renders without client-side JavaScript. Load the page with scripts disabled; if the main content or the structured data only appears after JavaScript runs, crawlers that do not execute it see an empty page.
10. Spot-check what assistants actually say about you. Ask ChatGPT, Claude, and Perplexity to describe your business and confirm the citations point at your pages; the answer they give is the real test of whether the plumbing works.

Proposed check. It flags output-cache policies whose vary-by keys do not account for per-visitor state such as anti-forgery tokens, authentication, or cart and session identity. When a response that embeds visitor-specific data is cached under a key shared across visitors, one person's page can be served to another. The same check flags the opposite smell: entries varied so finely, for example by a unique per-request token, that the cache never hits and the policy just adds overhead.

Sentinel flags reusable content items that have zero inbound references and either have not been edited within the staleness threshold (default 180 days) or have no modification metadata at all. It left-joins CMS_ContentItemReference and reports only items that nothing else points to: no page, no reusable-field link, no widget blob. Image-like and file-like types are deliberately excluded here because they are covered by the separate CNT010 and CNT011 checks, so an item never fires in two buckets. These are safe-to-delete or safe-to-archive candidates rather than errors, which is why each finding is Info severity.

Sentinel flags every content item language variant whose last-modified timestamp is older than the configured staleness threshold (StaleDays, default 180). It reads CMS_ContentItemLanguageMetadata joined to CMS_ContentItem and CMS_Class, so the age it reports is the real last-edited timestamp Kentico stores, not a guess from source code. Each finding names the item, its content type, and its exact age in days, ordered oldest first. This is a runtime check and needs a database connection (blank config reuses CMSConnectionString).

Proposed check, and the first in a new GEO category. It detects JSON-LD whose script contents have been HTML-entity-encoded on render, with angle brackets and quotes turned into <, >, and " inside a script type="application/ld+json" block. Entity-encoded structured data renders fine to a browser but is no longer valid JSON, so anything reading it as text parses nothing. The check targets Razor views and tag helpers that emit structured data through an output path that HTML-encodes by default.