1. Technical Foundation
Phase 1 of the engagement, run in Month 1: making the Aerion website and documentation readable and citable by AI systems. It covers the access files and crawler policy, Schema.org structured data, multilingual indexation signals, citable content formatting, and verification that the documentation surface is retrievable. This phase configures what already exists — writing the content base itself is Section 3.
1.1 AI access & crawler management
Assistants reach a site through declared crawlers. The Aerion site currently carries no configuration addressed to them, so access is left to defaults. This clause publishes the access files and states a rule for each named crawler.
- 1.1.1llms.txt is published at the domain root: a short machine-readable index naming what Aerion is, the canonical pages, and the entry points into the documentation.
- 1.1.2llms-full.txt carries the expanded plain-text description, so a retrieval system can take the full account of Aerion in a single fetch.
- 1.1.3Each declared assistant crawler — GPTBot, ClaudeBot, PerplexityBot and the peer crawlers published by the same operators — is given an explicit allow or disallow rule. Nothing is left to an implied default.
- 1.1.4The robots file is rewritten so the assistant rules sit alongside the search-engine rules and the sitemap is declared in the same place.
- 1.1.5Access rules separate the public surface from anything Aerion does not want retrieved: staging hosts, gated pages and internal documentation. Aerion confirms that list before the rules are applied.
- 1.1.6Every rule is checked after publication by requesting the affected paths and reading the response codes, so the published policy and the served policy match.
Boundary — What a crawler rule can do
A crawler directive states Aerion's policy to the operators that honour it. It is a published instruction, not an enforcement mechanism, and it does not remove content already held in a trained model. Where content must be withheld rather than requested to be skipped, it is placed behind access control instead.
1.2 Structured data
Structured data lets a model read Aerion's facts as labelled fields rather than infer them from prose. Four Schema.org types are applied across the site and documentation.
| Ref | Type | Applied to |
|---|---|---|
| SC-01 | Organization | The Aerion corporate record: name, description, logo, official address and the third-party profiles registered under Section 2. This is the record an assistant reads when asked what Aerion is. |
| SC-02 | Product | The $ARN token and the product surfaces described on the site, using the names, figures and wording Aerion has approved. No figure is published that Aerion has not confirmed. |
| SC-03 | FAQPage | The question-and-answer blocks on the site and in the documentation, so each answer can be lifted as a self-contained pair rather than parsed out of a page. |
| SC-04 | Article | Explanatory articles and documentation pages, carrying headline, publication date, language and author so a citation can be attributed and dated. |
- 1.2.1Markup is implemented as JSON-LD in the served page, so it is present without executing client-side code.
- 1.2.2The sameAs field on the Organization record points at the third-party profiles built under §2.2, so the site and those profiles resolve to one entity rather than several.
- 1.2.3Every value in the markup is taken from copy Aerion has approved. Structured data restates published facts; it does not introduce new ones.
- 1.2.4Markup is validated against the public structured-data validators before publication, and re-validated after each change.
- 1.2.5Where a page is republished in another language, the markup is emitted per language variant with the language declared.
1.3 Multilingual indexation
Aerion publishes in more than one language. Without explicit language signals, translated pages compete with each other, and an assistant may answer from the wrong variant or treat the set as duplicated content.
- 1.3.1One sitemap covers the published language set, lists canonical URLs only, and is regenerated as pages are added.
- 1.3.2Reciprocal hreflang annotations connect each page to its counterparts in the other languages, with an x-default entry for the fallback.
- 1.3.3One canonical URL is declared per page, so no language variant, parameter or duplicate path competes with the version Aerion intends to be cited.
- 1.3.4The language is declared both in the page markup and in the structured data emitted under §1.2, so a retrieved passage carries its own language.
- 1.3.5The sitemap is declared in the robots file per §1.1 and submitted through the search consoles Aerion already holds.
- 1.3.6This proposal is configured for the TR and EN set, confirmed by Aerion at kickoff. Adding a further language afterwards is a configuration change against the same structure, not a rebuild, and is quoted as a follow-up module.
1.4 Citable content formatting
An assistant cites a passage it can lift intact. Existing pages are restructured so that each answer sits in one self-contained block, in the served HTML, in a shape a model can quote without reassembling it.
- Definition blocks
- Each concept opens with the term, a single-sentence definition, then the expansion. A concept carries one canonical definition and appears in the same shape everywhere it is used.
- Data tables
- Figures are published as real tables with header cells, stated units and a caption line — not as images, and not as styled layout blocks that read as loose text.
- Answer-shaped headings
- Headings are written as the question a reader would actually ask, with the answer stated in the first paragraph beneath rather than built up across the section.
- Standalone summaries
- Each substantial page opens with a two- to three-sentence summary that still holds if it is the only passage retrieved from that page.
- Consistent naming
- One written form per entity — $ARN, POMP, Modus I and Modus II, and the other terms fixed in the glossary at §3.2 — so variants are not read as different things.
- Retrievable markup
- Answers stay in the HTML the server returns. Content held behind tabs, accordions or client-side rendering is moved into the served response or duplicated in it.
- 1.4.1The formatting rules above are applied to the existing pages Aerion nominates in this phase; new pages written later follow the same rules.
- 1.4.2The rules are written up as a short authoring standard, so the content produced under Section 3 is formatted the same way without a second pass.
- 1.4.3Reformatting does not change meaning. Where a passage is ambiguous, it is raised with Aerion rather than rewritten unilaterally.
1.5 Documentation indexation & phase deliverable
The documentation surface holds the most citable material Aerion owns, and is the surface most often unreachable in practice. This clause verifies that it is crawled and retrievable, and closes the phase.
- 1.5.1Every documentation page is checked for a crawlable URL, a server-rendered response, and inclusion in the sitemap published under §1.3.
- 1.5.2Pages excluded from indexation by an earlier configuration are identified and, where Aerion agrees they should be public, released.
- 1.5.3Retrieval is spot-checked in two directions: requesting pages as a declared crawler receives them, and asking the assistants for passages that exist only in the documentation.
- 1.5.4Findings are recorded per URL as reachable, retrievable or not retrievable, each with the cause stated.
- 1.5.5Fixes inside the site, CMS or documentation platform are applied within this phase. Anything requiring a change to a system Aerion controls elsewhere is listed for Aerion with the specific change named.
- 1.5.6The verification record becomes the baseline for the monthly measurement cycle described at §4.2.
| Ref | Work item | What is delivered |
|---|---|---|
| T-01 | Access files | llms.txt and llms-full.txt published at the domain root, per §1.1. |
| T-02 | Crawler access policy | Explicit allow or disallow rules for GPTBot, ClaudeBot, PerplexityBot and the peer assistant crawlers, plus the rewritten robots file, per §1.1. |
| T-03 | Structured data | JSON-LD markup for the four types registered at SC-01 to SC-04, applied across the site and documentation, per §1.2. |
| T-04 | Indexation signals | Multilingual sitemap, reciprocal hreflang annotations and one canonical URL per page across the confirmed language set, per §1.3. |
| T-05 | Citable formatting | Definition blocks, data tables and answer-shaped headings applied to the pages agreed with Aerion, per §1.4. |
| T-06 | Documentation verification | A per-URL record of what is reachable and retrievable, with the fixes applied and the causes recorded, per §1.5. |
| T-07 | Implementation report | A written record of every configuration applied, where it was applied, and how Aerion can re-check it without Polenist. |
- Deliverable
- Applied technical configuration plus an implementation report covering T-01 to T-07. The configuration is live on Aerion's own infrastructure; the report states what was changed, where, and how to verify it.
Boundary — Access and existing content
Polenist implements the configuration; Aerion supplies website, domain and DNS, CMS and documentation access, and the approvals needed to publish. Where access is not available, the affected item is specified in writing for Aerion to apply. Content that does not exist cannot be made citable — this phase makes the existing surface readable and quotable, and the content base itself is built under Section 3.