Entity Level Authority
Phase 2 Field Report

ELA Phase 2: Architectural Maturity and the Layer 2 Threshold

By Paul Joseph Bruemmer, Founder, Entity Level Authority

Executive Summary

Between May 2 and May 16, 2026, Entity Level Authority extended its own AI Search Visibility infrastructure through a second round of architectural work. The site's AI Search Visibility score moved from 65 to 69 in that period — a four-point gain that was substantially smaller than the 28-point move documented in Phase 1.

This case study documents what shipped, what moved, what didn't, and the lesson the smaller number actually carried. The headline finding is straightforward: ELA's Layer 1 architecture is now largely complete, and the remaining drag on the composite score lives in Layer 2 — entity recognition, structured data completeness, and the body of authorship and corroboration signals that determine whether an AI system treats the site as a citable source rather than a retrievable one.

The four-point move was not a disappointment. It was the architectural curve flattening exactly where the three-layer model would predict it should flatten. Phase 3 work will move into Layer 2.

1. What Shipped Between May 2 and May 16

Four pieces of work landed in this period. Three were additive architectural extensions. One was a negative result — an architectural approach attempted, hit a platform constraint, and abandoned in favor of a different path.

1.1 Edge-Rendered HTML for Crawler User Agents on Priority Routes

The platform — anonymized as it was in Phase 1 — hosts ELA's site as a JavaScript single-page application served behind Cloudflare. In the period between Phase 1 and Phase 2, a Cloudflare Worker was deployed to intercept requests from AI crawler user agents on four priority routes and serve pre-rendered HTML from a Supabase edge function. Human users continue to receive the SPA shell and the JavaScript-rendered experience.

The four routes covered by this Worker are:

These four routes were selected because they cover the highest-intent buyer paths: the service page, the vertical-targeted landing page, the FAQ page where direct-answer queries are most likely to retrieve, and the content library where topical depth lives. The four routes also represent the highest-leverage four-route subset for plaintiff trial firm visibility.

The Worker fires on the same URLs for both apex domain and www subdomain. Eight route bindings in total.

1.2 The Vite Prerender Experiment (Negative Result)

Before the Worker pattern was extended to multiple routes, an alternative approach was attempted: per-route prerendering at build time via the Vite build pipeline. The idea was to extend a working static-prerender plugin so that /faq, /ai-search-visibility-audit, /for/plaintiff-firms, and /blog would each get a fully-rendered dist/<route>/index.html at build time, served as static HTML directly through the platform's edge.

The approach failed. The constraint was specific and worth documenting: the platform's edge layer serves the main SPA index.html for extensionless paths before checking nested static files. A file at dist/faq/index.html would never be reached because the request to /faq was already being answered by dist/index.html (the SPA shell) before the edge routing layer looked deeper.

The approach was reverted. The revert is documented in source-file comments so that the next engineer evaluating this approach does not repeat the experiment without knowing the constraint.

This negative result clarified the architectural shape of what was actually viable on this platform: edge-rendered HTML at the Cloudflare layer (the Worker pattern), not build-time prerender at the application layer. The Worker approach succeeded for the same reason the Vite prerender approach failed — the Worker fires before the platform's edge serving logic gets a chance to serve the SPA shell.

1.3 URL Routing Infrastructure (Second Cloudflare Worker)

A second Cloudflare Worker was deployed to handle two URL correctness needs the platform's hosting cannot do natively:

The Worker uses a parameterized configuration pattern — a REDIRECTS map and a DIRECTORY_INDEX map — so that future URL migrations and new directory-index needs are one-line additions to the Worker code rather than architectural decisions. Adding a future case study namespace, a future methodology subpage, or a future renamed URL is a low-cost configuration change.

This infrastructure was a necessary precondition for publishing the methodology piece (Section 1.4) at a clean /methodology/ URL.

1.4 Methodology Documentation Published as a Permanent Reference

A two-version methodology piece was published at /methodology/:

Both pages are static HTML, served crawler-visible in raw HTML through Cloudflare. Both carry Article JSON-LD schema linked via stable @id references to the existing Person entity (for author attribution) and Organization entity (for publisher attribution) declared in the site's homepage schema.

The methodology piece serves two functions at once. First, it is a Layer 2 asset in itself — a focused topic page with clear authorship, substantive content, and stable entity-graph connections, which directly addresses the audit dimensions flagged as ELA's weakest. Second, it is the framework that explains why Phase 2's score movement was smaller than Phase 1's: architecture is necessary, not sufficient, and Phase 2 was almost entirely architectural work running into Layer 2 limits.

For the full framework that underlies the rest of this case study, see The Three-Layer Model: Why AI Visibility Isn't a Single Problem.

2. The Score Movement: 65 → 69

ELA's AI Search Visibility score moved from 65 on May 2 to 69 on May 16. The four-point increase is documented and reproducible against the May 16 audit run.

The composite score is the integer summary of seven sub-scores, weighted. Looking at the seven sub-scores tells a more useful story than the composite alone.

2.1 Sub-Score Profile (May 16, 2026)

A separate Brand Authority / Off-Site Presence module is available but not enabled in this audit run.

2.2 What the Sub-Score Profile Means

The Layer 1 dimensions — Crawler Access, Technical Foundations, LLM Discoverability, Citability, Platform Readiness — are between 73 and 100. These are the dimensions Phase 2's architectural work was meant to influence, and they are now largely complete.

The Layer 2 dimensions — Content Quality / E-E-A-T at 48 and Structured Data at 34 — are where the remaining drag lives. These are the dimensions that determine whether an AI system reading the site can confidently identify who the firm is, what it does, who the people are, and which third parties corroborate those claims.

The four-point composite move is what happens when architectural work continues to improve already-strong Layer 1 dimensions while Layer 2 dimensions stay where they are. The composite improves slowly because the dimensions doing the moving are the ones already near their ceilings.

2.3 What Did Not Move

The audit's bimodal visibility diagnostic flagged five of six analyzed pages as appearing "unstable / mixed" because of missing H1–H4 heading structure in the crawler-visible content. This includes the homepage, the blog index, the how-it-works page, and the AI Search Visibility Audit page — pages whose React components do contain heading hierarchy when rendered in a browser, but whose initial HTML response does not yet include those headings as raw HTML.

Three of the four flagged routes are now in the Worker's coverage. The fourth — the homepage — is not. The homepage is rendered as an SPA shell with no edge-rendered alternative for crawler user agents. This is a known gap.

A separate appendix in the May 16 audit, the Focused Coverage Diagnostic, flags that pricing is mentioned on the site but no dedicated focused-page for it exists. This is a topical-clarity gap.

The Schema Identity diagnostic in the same audit confirms that no canonical identity page exists on the site (a single page carrying Organization name, sameAs links, and contact details in one schema block). This is the canonical Layer 2 gap that the methodology piece formalizes.

3. The Lesson the Smaller Number Carried

Phase 1's 28-point move came from making a JavaScript-rendered site retrievable. Phase 2's four-point move came from extending that retrievability to additional routes and building the infrastructure to publish further reference content.

These were architecturally larger moves than what Phase 1 accomplished — multiple route patterns rendered, two Workers deployed, a permanent reference document published, URL routing made correct, an architectural negative result documented. The composite score moved less because the composite score is now constrained by dimensions Phase 2 did not address.

This is the architectural curve flattening at the right place. Phase 1 closed the largest single retrievability gap a JavaScript-rendered site can have. Phase 2 cleaned up the remaining retrievability concerns. Phase 3 has to be Layer 2 work, or the composite will not move much further.

The implication for plaintiff trial firms is direct: if your site is built on a JavaScript framework without SSR or pre-rendering, you probably have a Phase 1-shaped problem — a large retrievability gap that can be closed quickly with an architectural fix. If your site already renders crawler-visible content, you probably have a Phase 2-shaped problem — diffuse identity, thin practice-area pages, missing schema, no canonical identity page, no body of authored expertise. The first kind of problem is easier to fix. The second kind is more common.

4. Phase 3 Hypothesis

The next phase of work on ELA's own site will move into Layer 2. The specific changes are predictable from the sub-score profile:

Each of these is a discrete, testable change. The hypothesis is that Layer 2 work, executed concentrated on a handful of priority pages, will move the composite score more than the equivalent volume of architectural work would have at this point in the trajectory. Phase 3 will test the hypothesis.

5. Methodological Notes

This case study documents work on a single site — ELA's own — over a 14-day period. Three notes on what that does and does not show.

The site is the test bed, not a representative client. ELA's own site is small, focused, and built for documentation. It is not representative of the average plaintiff trial firm site, which is typically larger, less focused, and built for lead generation rather than methodology display. Phase 1 and Phase 2 findings are about what's possible on a controlled site; what's achievable on a typical client site depends on the client.

The score is a measurement instrument, not a goal. ELA's audit composite is one of several signals. It correlates with retrievability and citability under controlled testing, but the score is not itself the outcome — the outcome is whether AI systems retrieve and cite the site when prospective clients ask the kinds of questions plaintiff firm marketing teams care about. Score movement is a leading indicator. Citation testing is the lagging indicator and the one that ultimately matters.

Layer 3 is observed, not measured from HTML. This case study does not include AI citation test screenshots of the kind Phase 1 included. The work documented here is Layer 1 / Layer 2 architectural and content-graph work. Layer 3 citation testing requires fresh AI chat sessions, repeated runs, and tracking of citation behavior over time. That testing is the work of Phase 3 and beyond.

6. Reproducibility

The architectural infrastructure documented in this case study is available for inspection. Two Cloudflare Workers are deployed — one handles crawler-targeted SSR for priority routes, the other handles redirect and directory-index correctness — and both are observable in the site's response behavior. The methodology piece is at /methodology/three-layer-model.html. The first-phase case study is at /case-studies/ela-phase-1.html. The May 16 audit findings cited here are available on request.


Entity Level Authority publishes case studies as part of its commitment to documenting methodology rather than claiming results. Phase 3, focusing on Layer 2 entity recognition work, is in preparation.