3. Content Engine
Phase 3 runs across Months 2 to 4 and builds the bilingual (TR/EN) content base that lets Aerion surface as the answer for its target queries. It covers the query matrix the whole engagement is measured against, the concept glossary, the extended FAQ structure, comparison and positioning content, whitepaper-derived articles and the publication calendar. This section covers what is written and when it is published; the technical markup those pages depend on sits in Section 1 and the testing of the resulting visibility sits in Section 4.
3.1 Target query matrix
The query set is derived first, because everything else in this section is written against it and everything in Section 4 is measured against it.
- 3.1.1Candidate queries are drawn from three inputs: Aerion's stated priority queries, the vocabulary already used across the website and documentation, and the question shapes that assistants are observed to answer in this category.
- 3.1.2Each candidate is assigned to one of the five clusters below. A query belongs to exactly one cluster, so that a gap found later points at a definite piece of missing content.
- 3.1.3Clusters are sized rather than exhaustive: the matrix records the queries the engagement will actually write for and test, not every query that could be asked.
- 3.1.4The agreed matrix is frozen as the measurement baseline and is the query set tested each month under §4.1. Changes to it are made deliberately and dated, because a query added mid-engagement has no earlier reading to compare against.
- 3.1.5Each cluster is mapped to the content types at §3.6 so that no cluster is left without a piece of content that can answer it.
| Ref | Cluster | Example intent |
|---|---|---|
| CQ-01 | Product | Queries that name Aerion directly and ask what it is, what it does and how the platform works. These are the queries where an assistant either has a source to cite or has nothing. |
| CQ-02 | Category | Queries about the category Aerion operates in, asked without naming a brand. Aerion is a candidate answer only if the category content exists and is attributable. |
| CQ-03 | Comparison | Queries that place Aerion beside alternatives in the same category. Assistants answer these from whatever comparison material they can retrieve, so the material has to exist in a factual form. |
| CQ-04 | Definitional | Queries about the vocabulary Aerion uses. Each term is answerable on its own, independently of the page it originally appeared on. |
| CQ-05 | Investor-intent | Queries about the token, the calendar and how participation works. Answers here are factual and reference the published record; no return, performance or timing claims are written into them. |
3.2 Concept glossary
Aerion uses vocabulary that a model cannot infer. Each term is written once, as a self-contained citable definition, and every other page defers to that wording.
- 3.2.1One entry per term: a direct definition in the opening sentence, then the context in which Aerion uses it. The entry answers the question on its own, without the reader needing the page around it.
- 3.2.2Wording is fixed once and reused. A term that is described three different ways across the site gives an assistant three competing answers and no reason to prefer one.
- 3.2.3Entries are written in both languages against the same definition, so the TR and EN records do not drift apart.
- 3.2.4Terms already defined in the whitepaper keep the whitepaper's meaning; the glossary restates it in retrievable form rather than revising it.
| Ref | Term | Why it is defined |
|---|---|---|
| GL-01 | Curtailment | Recurs across Aerion's product narrative and is routinely mis-explained in general sources. A defined, citable entry stops assistants from substituting an unrelated definition. |
| GL-02 | POMP | An Aerion-specific mechanism whose name carries no meaning to a model without a definition attached to it. |
| GL-03 | $ARN | The token symbol. Needs an unambiguous entry so that the symbol, the project name and the network detail resolve to one record rather than several partial ones. |
| GL-04 | Modus I / Modus II | Two named operating modes. Defined together in one entry so an assistant asked about either returns the distinction, not one half of it. |
| GL-05 | Platform & operating terms | The remaining product vocabulary that appears in the website and documentation. Each term is given the same treatment: one definition, one place, one wording. |
| GL-06 | Token & participation terms | The vocabulary used around allocation, calendar and participation. Defined factually, with the boundaries stated in the source material preserved verbatim. |
3.3 Extended FAQ structure
The FAQ is written as retrieval material rather than as a support page. One question per block, answered in the first sentence, with the detail following.
- 3.3.1One question per block. Blocks are not merged and questions are not stacked under a single heading, because an assistant retrieves the block, not the page.
- 3.3.2Answers are answer-shaped: the answer comes first and the qualification comes after it. No block opens with background before it resolves the question.
- 3.3.3Every block carries FAQ structured-data markup as configured under §1.2. Markup without an answer-shaped block is wasted; an answer-shaped block without markup is harder to retrieve.
- 3.3.4Questions are taken from the query matrix at §3.1, not invented separately, so the FAQ and the measured query set stay aligned.
- 3.3.5Where a question touches the token or participation, the answer states the factual position and the stated boundaries around it, and makes no claim about outcome or timing.
3.4 Comparison & positioning content
Comparison queries are answered by assistants whether or not the material exists. This clause produces the factual version so the retrievable answer is one Aerion has written.
- 3.4.1Positioning content states where Aerion sits in its category, on attributes that can be checked against the published record.
- 3.4.2Comparisons are written factually and are limited to the alternatives Aerion agrees to name. Attributes compared are stated attributes; nothing is asserted about a third party that its own published material does not support.
- 3.4.3What Aerion does not claim to be is stated as plainly as what it is. A boundary written down is a boundary an assistant can repeat.
- 3.4.4No superlatives, no ranking language and no outcome claims. Comparative copy of that kind is the copy most likely to be contradicted by another source and discarded.
- 3.4.5Positioning wording is consistent with the glossary at §3.2 and with the source records established in Section 2, so the same narrative is retrieved wherever it is found.
3.5 Whitepaper-derived explanatory articles
The whitepaper already contains the substance. It is a long document written to be read in order, which is the format assistants retrieve least well.
- 3.5.1Topics are lifted out of the existing whitepaper and rewritten as standalone pieces, each answering one question from end to end without depending on the sections around it.
- 3.5.2The source material is not restated in full and not reinterpreted. Where the whitepaper sets a boundary or a condition, the derived article carries it across unchanged.
- 3.5.3Each article opens with the answer, then develops it, and closes by linking to the glossary entries and FAQ blocks that cover the terms it uses.
- 3.5.4Articles are published in both languages against the same source passage, so the TR and EN versions do not diverge from each other or from the whitepaper.
- 3.5.5Priority is set by the query matrix: whitepaper topics that map to a cluster with no other content are written first.
3.6 Content calendar & ownership
The calendar is the operating document of this phase. It records what is written, in what order, in which language, who approves it and when it is published. The Phase 3 deliverable is the published content set together with that calendar.
| Ref | Content type | Purpose | Language | Volume |
|---|---|---|---|---|
| CT-01 | Glossary entry | One term, one self-contained definition, written so it can be quoted without the surrounding page. | TR + EN | [count] |
| CT-02 | FAQ block | One question, one answer-shaped block, marked up as a question-and-answer pair. | TR + EN | [count] |
| CT-03 | Comparison page | Aerion set beside its category alternatives on stated, checkable attributes. | TR + EN | [count] |
| CT-04 | Positioning explainer | Where Aerion sits in its category and what it does not claim to be. | TR + EN | [count] |
| CT-05 | Whitepaper-derived article | A single topic lifted out of the whitepaper and rewritten as a standalone piece that answers one question end to end. | TR + EN | [count] |
| CT-06 | Definition block | A short definition or data table inserted into an existing page so that page becomes retrievable for a definitional query. | TR + EN | [count] |
- 3.6.1Every item on the calendar carries its query cluster, its content type, its language pair, its draft date and its publication date.
- 3.6.2Polenist drafts and prepares; Aerion reviews, approves and publishes. Ownership of each step is recorded per item so an item is never waiting on an unnamed party.
- 3.6.3Publication is paced across Months 2 to 4 rather than released in one batch, so that each monthly measurement cycle has new material to read against.
- 3.6.4Items are ordered by measurement value: clusters showing no visibility in the current cycle are served before clusters already answered.
- 3.6.5The calendar is carried forward into the monthly process, where it is updated from the gap analysis rather than rewritten from scratch.
Exclusion — Approval, publication and languages
Content is published under Aerion's approval. Copy that is not approved, or that is approved but not published, cannot be retrieved by an assistant and therefore cannot be measured; unpublished items are reported as pending rather than counted as delivered. Languages beyond TR and EN are a follow-up module: they are not part of this scope, not part of the setup fee, and not produced under this phase.