5. Aerion Inputs & Responsibilities

Polenist carries out the implementation described in the preceding four sections. This section records what Aerion supplies for that implementation to run: information, access, approvals, a named point of contact and the external budgets that sit outside this proposal. It adds no work to the scope of sections 1 to 4; it states the dependencies that scope runs on and the effect on the schedule when one of them arrives late.

Schedule of inputs · expanded at 5.1–5.6

Ref	Input	Needed for	Needed by
IN-01	Brand and product information	Positioning, product narrative, token calendar and priority target queries	At kickoff, then on change
IN-02	Website and documentation access	Website, domain/DNS, CMS and docs access for the technical configuration	Before Phase 1 work starts
IN-03	Third-party platform information	Company and project detail for Crunchbase, crypto directories, ICO platforms and media placements	Before each registration opens
IN-04	Point of contact	A named Aerion project owner coordinating with the Polenist team	At kickoff
IN-05	Approval and publication decisions	Copy and publication approvals for registrations, profiles, content and PR placements	Per item, throughout
IN-06	External budgets	PR and media placement budgets and third-party platform fees, held by Aerion	Before a placement is committed

5.1 Brand and product information

Polenist writes about Aerion using what Aerion supplies. The positioning, the product narrative, the token calendar and the priority target queries are the source material behind the query matrix, the glossary and the positioning content.

5.1.1The current positioning statement and the product narrative Aerion wants carried into AI answers, in whatever form it already exists.
5.1.2The token calendar, so the crypto directory entries at §2.2 and the content calendar stay synchronised with it rather than with a snapshot taken at kickoff.
5.1.3The queries Aerion treats as priority: the questions a prospective participant, partner or journalist would put to an AI assistant.
5.1.4Working definitions for the project-specific concepts — curtailment, POMP, $ARN, Modus I and Modus II — as the starting point for the glossary entries.
5.1.5The whitepaper and any existing documentation in their current published form, together with the versions they supersede where those are still reachable.
5.1.6Notice when the positioning, the narrative or the calendar changes, so published sources can be corrected rather than left to drift.

5.2 Website and documentation access

The technical configuration is applied to Aerion's own website and documentation. Polenist cannot publish a file, a header or a markup block without a route to those surfaces.

5.2.1Website and CMS access at a level that allows the access files at §1.1, the structured data at §1.2 and the indexation signals at §1.3 to be published.
5.2.2Domain and DNS access where a configuration has to be applied at that level rather than inside the CMS.
5.2.3Documentation access, including whatever build or publishing pipeline the docs are generated from, so indexation can be verified at the source and not only in the rendered output.
5.2.4A staging or preview environment where one exists, so configuration is checked before it reaches the live site.
5.2.5Whether Polenist applies each configuration directly or hands it to an Aerion developer to apply is decided at kickoff and recorded. Both are workable; direct access shortens the cycle.
5.2.6Access is scoped to what the work requires, is not shared beyond the Polenist project team, and is withdrawn on request.

5.3 Third-party platform information

The registrations and placements build a record of Aerion on platforms Aerion owns the facts about. Each asks for company and project detail that Polenist cannot supply on Aerion's behalf.

5.3.1Company detail for the Crunchbase profile: legal entity, founding information, location, funding status as Aerion wishes it stated, and team records.
5.3.2Project and token detail for the crypto directories and ICO listing platforms, in the form each platform asks for it.
5.3.3Brand assets: logo files at the sizes each platform requires, and descriptions at the lengths each platform allows.
5.3.4Completion of the verification steps that only Aerion can complete — those tied to a domain-controlled email address, an officer of the company, or ownership of an existing account.
5.3.5Administrative rights on the LinkedIn company page and the other corporate profiles being strengthened.
5.3.6Where a platform requires the submission to come from Aerion directly, Polenist prepares the submission in full and Aerion files it.

5.4 Point of contact

One named Aerion project owner coordinates with the Polenist team. A single routing point is what keeps information requests, access requests and approvals from stalling in separate threads.

5.4.1One named owner, with the authority to route requests inside Aerion and to obtain the approvals set out at §5.5.
5.4.2That owner is the single addressee for information requests, access requests, draft copy and monthly reporting.
5.4.3A named deputy for periods when the owner is unavailable, so the queue does not stop with one person.
5.4.4Where an item needs a decision from someone else at Aerion, the owner obtains it. Polenist does not pursue individual stakeholders separately.
5.4.5A short recurring review point in the monthly cycle, so the report and the action plan are read by someone able to act on them.

5.5 Approval and publication processes

Registrations, profiles, content and PR placements each carry a copy approval and, where publication is on an Aerion surface, a publication approval. These are the items most likely to sit still, and the schedule is built on them moving.

5.5.1Copy approval before a profile, a listing entry, an article or a PR text is submitted or published.
5.5.2Publication approval where the item is published on a surface Aerion controls.
5.5.3Approvals returned as a decision: approved, or approved with named changes. Consolidated feedback in one round wherever the item allows it.
5.5.4An item awaiting approval keeps its place in the queue. It does not consume implementation time and it is not silently dropped.
5.5.5A late approval moves the date of the affected item by the same number of days. Items not dependent on it continue, and the timeline at §6.3 shifts for that item only.
5.5.6Third-party platforms apply their own review times to a submitted registration or profile. Those sit outside the control of either party and are reported as they stand.

5.6 External budgets and third-party fees

Money payable to publishers and platforms is separate from the fee for this engagement. Polenist plans and prepares the placement; Aerion holds the budget and approves each commitment.

5.6.1Media and PR placement costs payable to a publisher are out of scope for this proposal.
5.6.2Paid listing, expedited review, verification and premium profile fees charged by directories and ICO platforms are out of scope for this proposal.
5.6.3Polenist identifies each such cost, states the published price where the platform publishes one, and reports them separately from the work fee.
5.6.4Nothing is committed on Aerion's behalf. Each item is submitted for approval before it is booked or paid.
5.6.5Registrations and placements available without a fee proceed without this step, and are the route taken wherever the platform offers both.

Exclusion — External spend

The fees in this proposal cover Polenist's work only. They do not include, and are not reduced by, any amount paid to a publisher, a directory, a listing platform or any other third party. Those amounts are reported for approval as they arise and are paid by Aerion.

Note

The materials Aerion provides under IN-01 to IN-06 may be updated, revised and extended as the project proceeds. The schedule above is the position at signature, not a closed list: as the work moves through the phases, new material is requested and superseded material is replaced.