2. Source & Authority Building
Phase 2 builds the third-party source network that lets AI models recognise Aerion as an entity: directory and profile registrations, a sector media and PR placement plan, corporate profile authority, and the source asset map that keeps every record consistent. It runs across Months 1–3, in parallel with the technical foundation. Polenist prepares, submits, tracks and maintains the records; paid placement budgets and third-party platform fees sit with Aerion and are reported separately.
2.1 Why third-party sources matter
AI models weight independent, structured records above first-party claims. A statement that appears only on Aerion's own site is a claim; the same statement carried by a directory entry, a profile record and an indexed media reference is treated as corroborated.
- 2.1.1Directory and reference records are structured, dated and attributed. They are read as facts about an entity rather than as marketing copy, which is why a single accurate listing can outweigh a page of website prose.
- 2.1.2Repetition across independent surfaces raises a model's confidence that the entity exists and that the description of it is accurate.
- 2.1.3Conflicting descriptions across surfaces are the main cause of wrong or hedged answers. Consistency across records matters more than the number of records.
- 2.1.4Records that answer engines read in real time — directories, profiles, indexed media — can affect answers on a shorter horizon than training data. Both are pursued here; the expected horizon for each is set out with the timeline.
- 2.1.5First-party pages remain necessary, because the third-party records point back to them. The technical work at §1.1 makes those pages readable and citable; this phase makes them corroborated.
2.2 Directory & profile registrations
Five registrations are opened, completed and kept current. Each is created from one approved description set, so the same facts appear on every surface. The crypto directory records are scheduled against Aerion's token calendar rather than submitted early with figures that will change.
| Ref | Source | What is registered | Timing |
|---|---|---|---|
| SR-01 | Crunchbase | Company profile: legal and trading name, short and long description, sector, founding details, locations, named team members and links to the primary sources Aerion approves. | Month 1 |
| SR-02 | CoinGecko | Token record: symbol, network and contract reference, supply and circulation figures, project description and official links. | Month 1–2, scheduled against the token calendar |
| SR-03 | CoinMarketCap | Token record carrying the same description set as SR-02, submitted separately under that platform's own listing requirements. | Month 1–2, scheduled against the token calendar |
| SR-04 | ICO listing platforms | Sale and project listings: sale phases and allocation information as published by Aerion, documentation links and the official contact route. | Month 2 |
| SR-05 | LinkedIn company page | Company page: name, industry, description, website, location and size fields matched to the Crunchbase record. Extended into executive profiles at §2.4. | Month 2 |
Limit — Platform acceptance
2.3 Sector media & PR placement plan
The placement plan sets out which channel types are worth pursuing, what each placement is meant to establish, and in what order they run against the token calendar. Polenist plans, prepares and briefs the placements; the budgets for paid placement are held and approved by Aerion.
| Ref | Channel type | Placement intent |
|---|---|---|
| PR-01 | Sector media | Crypto and energy-sector publications that answer engines index. The placement establishes an independent description of what Aerion does, written by someone other than Aerion. |
| PR-02 | Technical explainer | Whitepaper-derived explanatory pieces placed with publications that carry technical writing, so the concept vocabulary built at §3.2 also appears off-domain. |
| PR-03 | Executive commentary | Named commentary and interviews attributed to Aerion executives, tying identified people to the organisation so both resolve to the same entity. |
| PR-04 | Announcement distribution | Milestone announcements released in step with the token calendar, so directory records and media references carry the same dates and the same wording. |
| PR-05 | Ecosystem & partner channels | Partner, ecosystem and community surfaces where Aerion is described by a third party. The plan supplies the approved description set so those mentions match the directory records. |
- 2.3.1Polenist produces the plan: the channel shortlist, the sequencing against the token calendar, and the brief and copy for each placement.
- 2.3.2Aerion approves each placement, its copy and any commercial terms before the placement is committed.
- 2.3.3Polenist does not commission paid placement on Aerion's behalf. A specific cost is submitted for approval and commissioned only once Aerion has approved it.
- 2.3.4Live placements are recorded in the source asset map at §2.5 with an owner and a review date, so a placement that goes out of date is found rather than forgotten.
Exclusion — Out of scope
2.4 Corporate profile authority
Entity resolution — a model deciding that every mention refers to the same organisation — depends on the same name, description and identifiers appearing on every surface. One approved description set governs all of them.
- 2.4.1The LinkedIn company page registered at §2.2 is completed and maintained: name, industry, description, website, location and size fields matched to the Crunchbase record rather than written independently.
- 2.4.2Executive profiles carry the same organisation name and the same role wording, so named people and the organisation resolve to a single entity.
- 2.4.3One naming convention is approved and applied everywhere: the organisation name, the product naming and the token symbol are written identically, including capitalisation and spacing.
- 2.4.4One short and one long description are held as the canonical text. Every registration, profile and placement draws from them instead of being rewritten each time.
- 2.4.5Identifiers are listed once and repeated without variation: website domain, documentation domain, contract reference and the official social handles.
- 2.4.6Where a surface allows only a shorter field, the approved text is truncated from the canonical version rather than reworded, so the wording never drifts.
- 2.4.7The same values populate the structured data published under §1.2, so the first-party markup and the third-party records state the same thing.
2.5 Source asset map
The map is the maintained register of every place Aerion is described. It is a working document kept for the duration of the engagement, not a one-off audit: each record carries an owner and a review date so it can be corrected by whoever holds it.
- Surface
- The platform, publication or profile the record sits on, with a direct link to it.
- Record type
- Directory entry, token record, company profile, executive profile or media placement, keyed to its reference at §2.2 or §2.3.
- Published description
- Which version of the approved description set the surface currently carries.
- Owner
- Who holds the account or the relationship — Polenist, Aerion or the third party. Only the owner can change the record.
- Access route
- Where the login or the submission route sits, so a record can be corrected without rediscovering how it was created.
- Last review
- The date the record was last checked against the approved description set.
- Status
- Live, submitted, under platform review, or declined with the reason the platform gave.
- The source asset map itself, current at handover and maintained from then on.
- The registrations at §2.2, submitted and each with its platform status recorded.
- The placement plan at §2.3, sequenced and approved.
From Month 2 the map is reviewed inside the monthly cycle at §4.2: records that have gone stale, listings that a platform has changed, and surfaces that have appeared without Aerion's involvement are picked up there rather than at the end of the phase.