Epovest

Accept one discovered suggestion (domain) or a batch (domains): each becomes a tracked keyword of the tracker, in place, and its series starts at the next survey. Refused with keyword_cap_reached when the batch would exceed the keyword cap, and with not_found when a domain is not currently suggested (the batch is all-or-nothing, nothing is added then). The answer carries keyword for a single domain, keywords for a batch. Accept on behalf of the user only when they said yes.

Add a check of your own to the checklist of one surface: a requirement the person holds on THAT page, in their words. It becomes REQUIRED for the page to count as aligned, exactly like the canon items of the template, and it is ticked with tick_surface_checklist at the key returned here. Reach for it whenever the person states something a page must carry that is theirs to decide: the pricing block quotes the canon boilerplate, the OG image is the current one, the footer carries the legal name, the pinned post links to the launch page. restates_canon is the one judgement to make, and the question is simple: does the tick become FALSE when the wording of the canon changes? True for a check that restates the canon, and its verification then perishes with the wording, putting the page back in the queue; false, the default, for a check that constates anything else, and the tick then stands until someone clears it. Sending the same label again returns the check already there, and brings it back from the trash if it was in it, so a replay never duplicates. Up to 20 checks on a surface.

Record that the page is no longer there (article unpublished, link dead), or put it back live with archived false. Nothing is deleted: the line stays, and so does the history, because "they talked about us from March to July" is information. A page taken down stops counting as a presence on that source. Only take down after actually re-reading the address and finding it gone.

File a project away once the folder has served its purpose: a client that left, a brand that was sold. It moves to the end of list_projects with archived true, and stops being offered when filing a tracker. Bring it back with archived false. Nothing is deleted and nothing cascades: the trackers filed under it keep their status, keep measuring and keep showing up in list_trackers, and the answer carries tracker_count, how many are still filed under it, so you can go on with archive_tracker on each one when that is what the user meant. Filing away an already filed project answers the same. Default is where trackers without a folder live: it has no id, so this tool always takes the UUID of a project of the account.

File a finished tracker away: a campaign that ended, a brand that was sold, a trial that is over. It moves to the end of list_trackers with archived true, stops asking for anything, and its measurement pauses in the same call if it was still running, so the spending stops there. Bring it back with archived false: the tracker returns to the list as it was, and start_tracker restarts the measurement when the user asks for it. The sheet and the score series are kept and stay readable throughout (get_results answers as usual). Filing away an already filed tracker answers the same.

Mark a quest done: the move happened. Sets the state and the closing date; calling it again leaves it done, so a retry is safe, and a dismissed quest that was done after all becomes done (the last move is what the file remembers). The quest stays readable in the closed history of list_quests, and reopen_quest puts it back in the file.

Send a message to the humans behind Epovest: report a problem, suggest an improvement, ask a question. Use it when a tool refuses what should work, when the product is missing something the user needs, or when the user asks you to tell us something. The message lands in the support threads of the account, which the members also see in the app, and a human answers there. Reply to an ongoing thread with thread_id, and read the answer with get_support_thread.

Move the page to the surface registry: the customer has, or takes, the final say on it (their own profile or listing recorded on the wrong side, or a source that became a reliable channel). Nothing is retyped: url, label and notes travel, the publication date is copied into the notes, the type derives from the address. The corroboration is taken down, sheet intact, and the reverse move exists (convert_surface_to_corroboration): nothing is lost, and replaying the move finds the same line instead of duplicating it. It moves a line the customer declared: confirm with the user first.

Move the page to the corroboration registry: someone else has the final say on it (the customer lost, or never had, the hand on the content). Nothing is retyped: url, label and notes travel, the publication date stays unknown (set it with update_corroboration when known). The surface leaves its registry for the trash, alignment journal attached, and the reverse move exists (convert_corroboration_to_surface): nothing is lost, and replaying the move finds the same line instead of duplicating it. The own site of the brand is refused (own_domain): it stays a surface. It moves a line the customer declared: confirm with the user first.

Record a page about the brand where someone else has the final say. URL-FIRST: the exact address of the page is the only thing needed, the source on the map and the display name are derived from it. It is a statement of fact: only record a page you have actually read, and confirm with the user. A page the customer controls (their own profile, their own listing) belongs to Surfaces instead: use create_surface. Three refusals answer with their own slug: unplaceable_url (the address has no registrable domain), own_domain (this is the own site of the brand, where they have the final say: use create_surface), duplicate (the page is already in the registry, 409).

Record an action in the logbook of a project: what was done, and WHEN it was done. occurred_at is the date of the ACTION itself, not of the recording: recording after the fact is the normal case ("record: site translated into Spanish yesterday" means occurred_at is yesterday). The entry joins the tool events in the logbook and lands as an annotation on the citation curves of the trackers of the project, so the action can be read against the measures. Recording is idempotent on the project, the label and occurred_at: calling again with the same three returns the entry already recorded instead of a second copy, so a retry is safe. The same move recorded in two languages has two labels, so it stays two entries.

Create a project to file trackers under: one project per BRAND, never per language. It can carry the brand canon: the reference wording every publication reuses as is, written in ONE language, its canonical language (carried at creation, it is recorded as canon version 1). The canon is never translated: localized expressions on the pages are outputs, not a second canon. Nothing is filed by this call: pass the returned id as project_id when creating or updating a tracker. Refused with project_exists when a project with this name already exists, and the answer carries the existing project: reuse its id instead of duplicating.

Add a quest to the file of a project: a next move the customer decided, kept where the work resumes ("get our MCP server listed on the AI tool directories"). title says the move; notes carry context and links. Adding is idempotent on the project and title while the quest is open: calling again returns the quest already in the file instead of a second copy, so a retry is safe. A closed quest with the same title does not block: doing the move again later is a new quest, with its own history.

Register a surface of a project: one page about the brand where the customer has the final say (their site, their profiles, their listings, wherever they can change the content). URL-FIRST: the url is the only thing needed, type and label are derived from it; pass them only to correct a derivation. It is born never_aligned: bring the page in phase with the canon, then record what it carries with tick_surface_checklist, cell by cell. The aligned status DERIVES from those verifications and is never declared: verifying the last canon cell aligns the surface on its own.

Create a tracker in draft. It measures nothing yet: call start_tracker to launch it against the prepaid credit balance. Validation rules and messages are the same as the app configurator. Omitted, next_survey_at means the first survey runs at start_tracker.

Take a manual logbook entry out of the logbook, and the annotation it placed on the curves with it. Only do it when the user asked for it: it is their logbook. The entry waits in the trash, so restore_logbook_entry brings it back with its annotation. Tool events stay as they are: they are derived from the canon and surface registries.

Take a surface out of the registry: the page stops being followed, and the registry stops asking to bring it in phase with the canon. Use it for a page that is gone (account closed, listing removed) or for a line that had no place there. The sheet and the alignment journal are kept, and restore_surface brings the surface back with them, so a line taken out by mistake costs nothing. Taking out an already taken out surface answers the same.

Take a check of your own out of the checklist of a surface: it leaves the list, stops holding the page short of aligned and stops accepting ticks. Use it when the requirement no longer applies to that page. Nothing is lost: the check and the cells it carries are kept, read back in checklist.custom with deleted true, and restore_surface_check brings both back, so a check taken out by mistake costs nothing. Taking out an already taken out check answers the same.

Refuse a suggested page: it is never proposed again for this project. Use it when the excerpt matched something else than the brand, or when the page is not worth recording. Nothing is created or deleted. Accepting is the opposite move and has no tool of its own: call create_corroboration with the url of the candidate, or create_surface when the page is one the customer controls.

Dismiss one discovered suggestion (domain) or a batch (domains): the domains are never proposed again on this tracker, and appear in the dismissed list until restored. All-or-nothing on unknown domains: one that is not currently suggested refuses the whole batch (not_found). Dismissing an already dismissed domain is fine, it does not fail the batch. The answer carries dismissed as the domain for a single call, the list for a batch.

Set a quest aside: the customer decided the move is off. Sets the state and the closing date; calling it again leaves it dismissed, so a retry is safe. The quest stays readable in the closed history of list_quests, and reopen_quest puts it back in the file.

The settings of the account: the legal name, billing country, postal address and intra-EU VAT number printed on its invoices, plus the language we write to it in and the time zone its hours are shown in. `member` names the person the language and the time zone belong to. Read it before update_account_settings: the answer gives every setting as it stands, so you change the one the user named and leave the others alone.

The prepaid credit balance of the account: available credits, the amount reserved by surveys in progress with the detail of each reservation, when the credits expire and until when the data-access window is open. Read it before starting a tracker, or when a call fails with insufficient_credits or data_access_expired. It also carries what a top-up is worth here, so you never have to work it out: `monthly_estimate_minor` is what the account has set up to consume in a month, and `suggested_topups[]` gives three amounts derived from it, each with `amount_minor`, `amount` (major units) and `covers_months`, the runway it buys at that pace. `min_topup_minor` is the floor a top-up has to clear. When the account consumes nothing yet, `monthly_estimate_minor` is 0 and the suggestion, if any, carries `covers_months: null`: it buys twelve more months of the data-access window rather than runway.

The addresses of the brand that a watched page can link to. Two lists come back. derived: what is already covered without anyone typing it, each row with its source, "canon" (the canonical website of the brand) or "surface" (a page of the surface registry: the site, the LinkedIn or X profile, a directory listing, an app store page). free: the addresses set on the project on top of those. Read it before setting anything: an address already derived does not need to be added, and the derived list is what the customer gets for free from work already done. A link towards any of these is what the reading pass reports on, with its rel tokens, its anchor, its destination and its place on the page.

The logbook of a project, newest first: every dated move, composed from two sources. source=tool events are derived from the suite itself (canon moved to a version, surface marked aligned, corroboration recorded); source=manual entries are actions the customer recorded (only these carry an id, a category, a label and notes). Each move also lands as an annotation on the citation curves of the trackers of the project: read the logbook to tell what was done when the curves moved. On a corroboration item, occurred_at is the PUBLICATION date when known and the recording date otherwise: published_on sits next to it, and it tells which of the two dates the move carries. Set deleted to "only" to read the trash of the logbook instead of it.

The raw answers of ONE AI engine for a tracker, newest surveys first, paginated. Every answer carries its cited sources and keyword mentions, plus uncited_sources (the pages the engine read without citing them) and searched (whether the engine went to the web to write that answer; null when undetermined). Set include_raw to add the full engine payload; heavy, ask for it only when needed.

The score series of a tracker: one row per analyst, keyword, engine, tracker version and survey period, in chronological order. Depending on the analyst, a row carries citation_rate and weighted_score, share_of_voice, or sentiment counts.

One entry of the Atlas, read by its id: the domain and its AI Authority on each AI. Call list_sources to find a source id, or to read the same entries filtered and ranked.

One support thread with its messages, including the answers of the support team. Read it back after contact_support to relay the answer to the user.

What the account SPENDS: one call, three answers, and they must never be mixed up. (1) THIS MONTH, a FORECAST: `this_month_forecast` gives `total_minor` for the month in progress, which is `spent_minor` (already debited) plus `remaining_minor` (what the active trackers and monitored corroborations will still run before month end, counted as real occurrences and recomputed from their configuration). Report it as a forecast, never as spend, and say the month. (2) PER MONTH, actual: `by_month[]` gives, for each of the last 12 months, `month` (YYYY-MM), `spent_minor`, and the same amount by project and by tracker. This is what the wallet was really debited. `months_total` says how many months have spend, so you can tell whether 12 covered everything. (3) OVER THE WINDOW, actual: `total_spent_minor` with `by_project[]` and `by_tracker[]` (biggest spender first) is a cumulative total over `period` (`from` and `to`, the first and last debit counted), never a monthly figure: quote the period alongside the amount. `entries[]` carries the ledger itself. Spend is broken down by COST LINE everywhere, in `lines` and `by_category`: `survey` (the checks themselves), `ai_analyst` (the supplement of the AI analysts grafted onto them), `corroboration_check` (monitored corroborations, one debit per check run) and `other` for a line the tool does not name yet, which stays visible rather than dropping out of a total. Amounts are in minor units of the wallet currency. Filter a single month with `month` (YYYY-MM), and the entries alone with `type` (`in` for top-ups, `out` for spend). Every tracker line carries `tracker_id`, ready for get_results or get_responses, and `listed` says whether that tracker is still in the account list. Each entry is stamped with `created_at`, the exact instant it was posted (RFC 3339, to the second, with the fraction the ledger recorded): an active account posts dozens of entries a day, so quote the time along with the date and let it order the entries of one…

The MENTIONS a search engine has shown the brand in, found in the text the engine itself returned next to each address. The list is recomputed on every read from the raw payloads of the latest surveys, and surveys_scanned says how many were read. Pages already filed in either registry (corroborations or surfaces) are left out. Each row carries the excerpt as proof, matched_by ("website" means the full domain of the brand appears in it, near proof; "name" means only the name did, weaker, homonyms exist: read the page before recording) and suggested: the registry the filing is proposed in ("surface" when the host is a known profile place, a page the customer usually has the final say on; "corroboration" otherwise). Once the page itself has been read, the row also carries page_check: result is "website" or "name" when the page carries the brand, "absent" when the page reads without it, and it names the cause when the text did not come: "blocked" (an anti-bot stands in front of the page), "unreachable" (the page did not answer), "no_page" (the address answers with something that is not a page), "unreadable" (the page answers HTML with no text in it). In those four the engine excerpt above stays the proof shown. excerpt is a full passage taken from the page, and checked_at dates the reading. It is a suggestion, never a filing: to file one, call create_corroboration or create_surface with its url; to refuse one, dismiss_corroboration_candidate.

The corroborations recorded for a project: the pages about the brand where someone else has the FINAL SAY, each with its exact address, the source it sits on (domain), the publication date when known, and free notes. Live ones first, then the ones taken down (archived true). The twin registry of Surfaces, where the customer has the final say: the split is control, never who wrote the page or who paid for it. Asking such a source for a change stays a normal move; record the outcome in the logbook. What comes back is what the customer DECLARED: the registry is theirs to fill, and list_corroboration_candidates proposes pages the engines already showed the brand on.

The keyword suggestions DISCOVERED on a tracker: domains the surveyed engines cite as sources again and again, that no tracked keyword covers. Recomputed on every read, from the recurrences the surveys have accumulated. Also carries dismissed, the domains this tracker has set aside: what was refused stays readable, so you can restore one with restore_keyword_discovery if the user changes their mind. The two lists are disjoint (a dismissed domain is never suggested). Relay the suggestions to the user: the decision to track a name is theirs.

The projects of the account: the folders trackers are filed under (one project per tracker at most; pure organization, no effect on measurement or billing). Each carries its id, name, brand canon with its current version number (canon_version), archived flag and tracker count. The folders still in use come first, then the ones filed away (archive_project). Trackers without a project live under the virtual Default project.

What there is to do for the GEO work, and where to resume it. Lists the quests of the account: moves the customer (or you, on their behalf) decided and recorded, open by default, newest first; status=done or dismissed reads the closed history, which answers with its quests, each one reopened with reopen_quest. Every project by default; scope to one project with project_id. Alongside the open file, `pending` carries the files the measurement is holding for review, each acted through its own tool: surfaces whose canon moved since their last alignment (list_surfaces, then tick_surface_checklist to verify the cells the new wording perished), keyword discoveries waiting on a tracker (list_keyword_discoveries, then accept_keyword_discovery or dismiss_keyword_discovery). Scoped to one project, `pending` also carries the corroboration candidates of that project, computed per project (list_corroboration_candidates, then create_corroboration or dismiss_corroboration_candidate). An empty file with the measurement running means there is nothing to correct today.

The Atlas: the sources the AIs cite when they answer YOUR trackers. Each entry is a domain with its AI Authority on each AI, a 0 to 100 scale over the last 30 days where 100 is the source that AI cites the most. An engine with no value has not cited the domain lately, which is not a zero. Each AI has its own leader, so its own scale: each column ranks the sources on its own AI, the rankings being almost disjoint. The map carries the sources surfaced by the surveys of this account, so it grows as the account measures more; filter it to one brand with project_id. The scale, on the other hand, is computed across every measurement Epovest runs, which is what makes it stable. Use it to see where an answer comes from on a subject, and which places are worth existing on. The unit is the registrable domain, so a subdomain is folded into it and a hosting platform counts as one source, not one per author.

The support threads of the account, most recent first: what was asked, and whether the support team has answered. The threads are shared by the members of the account, whatever wrote them.

The surface registry of a project: the pages about the brand where the customer has the FINAL SAY (website, GitHub, LinkedIn, X, YouTube, Wikidata, directories, app stores...). The split with corroborations is control, never who wrote the page: a page the customer can change is a surface, a page where someone else has the final say is a corroboration (list_corroborations). Each surface carries its type, url, label, languages, notes, its checklist and a status DERIVED from the checklist CELLS that hold it: checklist.required lists exactly those, the canon items of the template plus every check the customer added of their own. checklist.kinds answers a different question, what PERISHES a tick: "canon" items restate the canon, so their verification perishes when the wording moves; "presence" ones, such as site_link, hold. A check of the customer holds the status whatever its kind, so read checklist.required and deduce nothing from checklist.kinds. checklist.custom lists those checks, each with its key, label, scope and restates_canon, and the ones taken out with deleted true, which restore_surface_check brings back; add_surface_check is how a new one is posed. Each cell is verified (dated, stamped with the canon version whose WORDING it restated: it stays fresh until the wording moves, and a revision that touches no wording, such as declaring the canonical language, perishes nothing) or set aside with its reason (the item does not apply on THIS surface). Three statuses, never a fourth: aligned when every required cell not set aside is verified at the current wording; needs_update when some verification is missing or stale; never_aligned when none exists. There is no state for a page the canon does not apply to, because setting aside the LAST canon cell is refused with not_a_surface, because a page that carries none of the canon is not a surface: turn it into a corroboration if someone else has the final say on it, or take it out of the registry. checklist.state keeps…

List the trackers of the account, current versions: configuration, status, keywords, analysts, project and the recalculated cost per survey. Start here to find a tracker id. Filter by project with project_id. The ones still followed come first, then the ones filed away (archive_tracker), each with archived true and its archived_at.

Pause the measurement of an active tracker. The score series is kept; start_tracker resumes it.

Correct the name of a project: the folder keeps its id, its canon, its trackers, its surfaces and its logbook, and the name shown is the only thing that changes. Names are unique per account: a name another project already goes by answers project_exists with that project, so read it back and settle another name with the user. Case, accents and spacing do not make two different names, which is why a project can always take back its own capitalisation. Sending the name it already carries answers the same, and a project filed away renames like any other. Use it for the name of the folder; the wording of the brand itself is the canon, and it moves with update_project_canon.

Put a closed quest back in the file: it returns among the open moves with its sheet as it was, the date it was added, its author and its notes, so a quest closed by mistake or taken up again keeps its own history. Clears the closing date; calling it again leaves it open, so a retry is safe. Call list_quests with status done or dismissed to find the quest to reopen.

Restore one dismissed domain (domain) or a batch (domains): it leaves the tracker dismissed list and becomes eligible for discovery again, suggested anew while the engines keep citing it (accepting it stays a distinct move). The counterpart of dismiss, for when the user changes their mind. Idempotent and never refused: restoring a domain that was not dismissed simply leaves it eligible. The answer carries restored as the domain for a single call, the list for a batch.

Bring an entry back to the logbook, with the annotation it placed on the curves. Call get_logbook with deleted set to "only" to find the entries to bring back. Restoring an entry already in the logbook answers the same.

Bring a surface back to the registry, with its sheet and its alignment journal as they were. Call list_surfaces with deleted set to "only" to find the surfaces to bring back. Restoring a surface already in the registry answers the same.

Bring a check of your own back to the checklist of a surface, with the cells it had: it becomes work again, so the page needs it verified to count as aligned. The checks to bring back are listed by list_surfaces in checklist.custom, with deleted true. Restoring a check already in the checklist answers the same.

Set the addresses of the brand that are neither its canonical website nor a page of the surface registry: a satellite domain the customer does not want to keep aligned, a tracking link, a partner page. They are set ONCE for the project and serve every line of the corroboration registry, present and future, so there is nothing to set line by line. The list you send REPLACES the previous one, and the answer returns what the project now holds, derived addresses included: read it back to confirm. An empty list keeps only the derived ones. Call get_link_targets first, and confirm with the user before replacing.

Start or restart the measurement of a tracker against the prepaid credit balance. Refused with insufficient_credits when the balance does not cover one survey. Starting an already active tracker changes nothing.

Run one survey of a measuring tracker right now, on top of its schedule. Its settings stay as they are: same anchor, same frequency, and the next scheduled survey keeps its date. It debits the prepaid credit balance like any survey, and the point joins the score series marked on_demand. The answer carries the survey id: read the results back with get_results, or the raw answers with get_responses. While one is still running, calling again answers that survey instead of starting a second one. Refused with insufficient_credits when the balance does not cover it, and with tracker_not_active when the tracker is not measuring yet: start_tracker first.

Record what a surface actually carries, cell by cell, as many moves as you want in one call. The items are listed by list_surfaces as checklist.items: the template of the surface type (stable keys such as title_tag or llms_txt), then the checks the customer added of their own (add_surface_check), which tick here exactly like the rest, at their key. Most of them are yours to check (a title tag, JSON-LD, an llms.txt all read with a simple fetch). Three moves per cell. VERIFY (done true, or nothing): the item is constated on the page; an item of canon kind (checklist.kinds) is stamped with the current canon version and wording, so its verification stays fresh until the wording moves, and needs the canon set first. SET ASIDE (dismissed true plus a short reason): the item does not apply on THIS surface (an author bio, a field the platform does not offer); durable across canon revisions, reversible, never hidden from the counts. CLEAR (done false, or dismissed false): the cell returns to blank. A site-wide item (checklist.site_items: the llms.txt, one file at the root of the site, written in the canonical language of the project) is one cell for the whole site, without a language. Only the cells you send change; an unknown item or language, a set-aside without reason or a contradictory move refuses the whole batch and says what exists. The ALIGNED status derives from the cells listed in checklist.required, the canon items plus the checks of the customer: verifying the last one aligns the surface and dates it in the journal. The goal is a surface with no required cell left undecided: work every one of them to a verdict, verified when the page carries it or set aside with a reason when the item does not apply here. Leaving a cell untouched is not a neutral skip, it holds the surface in needs_update and hides whether the page was ever checked, so go through the whole checklist and not only the cells easy to confirm. And setting aside the LAST canon cell is refused, because…