Source Policy

Most bad automation advice is not invented. It is copied from something that was true a year ago, or from a confident answer that was never true at all. This policy sets out what MetaFlowKit accepts as evidence, and what we will not cite.

Our source hierarchy

Sources are ranked by how directly they establish the claim being made. A platform rule can only be established from the top two tiers.

1. Official platform material and direct observation. The vendor’s current documentation, release notes, status pages, published pricing and limits pages, and the product interface as we directly observe it. This is the only acceptable basis for stating a rule: what a plan costs, what a limit is, how a platform counts an execution, or what a node or app supports.
2. Standards bodies, regulators, and original technical specifications. Where a claim depends on something outside the vendor’s control — an authentication or webhook specification, a data-format standard, a regulatory requirement — we go to the defining document, not a summary of it.
3. Reputable secondary reporting. Established technical publications and vendor-adjacent analysis are used for context and history, and to identify that something changed. They are never the sole basis for a technical rule, because they carry the same staleness risk we are trying to avoid.
4. Community and forum reports. Support forums, issue trackers, and public discussion are treated as symptom and discovery signals. They show that people are hitting something, often earlier than any documentation does. They are never sole proof of a platform rule.

In practice, a forum thread can start an investigation, but the sentence stating what the platform actually does must trace back to tier one or two.

Exact links and access dates

Update-sensitive claims carry a link to the specific page that supports them and the date that page was checked.

Exact means exact. We link to the documentation page covering the setting in question, not to a documentation home page, and to the relevant section where one exists. Where a claim depends on a versioned document, we identify the version.

The access date is recorded because vendor documentation is edited in place, usually without a visible revision history. A dated claim lets a reader judge staleness independently rather than trusting that a page is current. Where a claim also depends on a platform version, plan tier, or region, those are recorded alongside the date, because the same documentation can be correct for one plan and misleading for another.

Screenshots and interface observations

Screenshots presented as evidence on this site are original captures from actual use. They are not vendor marketing images, not taken from other publications, and never generated. Decorative featured illustrations may be generated, but they are not presented as screenshots or evidence.

Each screenshot used as evidence is labelled with the platform, the relevant version or interface state where that matters, and the date of capture. An undated interface screenshot is a claim with no expiry, and these platforms redesign often enough that it will mislead within months.

Before publication, screenshots are reviewed for sensitive content. Credentials, API keys and tokens, webhook URLs and signing secrets, account identifiers, email addresses, and customer data are blurred or removed. Where blurring would destroy the point of the image, we substitute placeholder data and say so.

Interface observations described in text follow the same rule: we describe what we saw, with date and version, and never a screen we have not opened.

Calculations and worked examples

Numbers presented without their derivation are unverifiable, so every calculation publishes its working:

• The formula used to produce the result, in a form the reader can apply themselves.
• The assumptions behind each input — run frequency, items processed per run, retry and error re-run behaviour, branch execution, and how the platform counts a billable unit.
• The origin of the inputs. Volumes and scenario figures are synthetic unless explicitly stated otherwise. Rates, prices, and limits taken from a vendor carry their source link and check date.
• The exclusions. What the calculation deliberately leaves out — manual runs, sandbox activity, sub-workflow counting, taxes, plan allowances, or anything else — is stated, since omissions are where estimates break.
• The limitations. Where the model stops being reliable — unusual volumes, plans with different counting rules, or designs the formula was not built for.

A calculated result models what should happen; it does not measure what did. We do not present synthetic arithmetic as account telemetry or as a billing outcome.

When sources conflict

Conflicts are common: documentation lags a product change, a pricing page and a limits page disagree, or two official pages describe the same feature differently. Our approach, in order:

1. Prefer the most current primary material, and check whether the apparent conflict is really a version, plan, or region difference.
2. Check whether direct observation of the product resolves it, and if so, record what was observed, when, and under what conditions.
3. Where the conflict survives, state it. The page describes both positions, identifies which source supports each, and says that we could not resolve it.

We would rather publish an honest unresolved conflict than pick the convenient answer and present it with false certainty. Where the uncertainty could affect cost or stability, the page says what to verify in your own account first.

Broken and changed sources

Vendor documentation is moved, merged, restructured, and deleted. When a source behind a published claim breaks or changes, we treat that as a signal to re-verify rather than as a formatting problem.

The claim is re-checked against the current primary source. If the vendor’s position has changed, the page is corrected and the change recorded, following our Editorial Policy. If the source has moved, the link is updated and the access date refreshed. If no current equivalent exists, the claim is re-sourced or removed — we do not leave a statement standing on evidence that no longer exists, and we do not present an archived copy as a current rule.

What we will never cite

• Invented citations. No source is listed unless it was opened and confirmed to support the claim it carries.
• Search-result pages. A link to a search query is not evidence.
• Circular sourcing. An article citing another article citing a third, with no primary document at the base, establishes nothing. We also do not cite our own pages as the source for an external fact.
• AI output. Text generated by an AI system is not a source and cannot verify a platform rule. Citations produced by AI are opened and confirmed before use, or discarded.
• Unsupported vendor claims. Marketing statements about reliability, speed, or capability are attributed as vendor claims, not repeated as fact.
• Unsupported community claims. A widely repeated forum answer is still a forum answer until a primary source confirms it.

Anonymous and confidential sourcing

Ordinary technical guidance should not depend on sources a reader cannot check. If a claim about pricing, limits, or platform behaviour can only be supported by an unnamed insider, it is either verifiable from primary material or it stays out of the article.

MetaFlowKit does not currently rely on confidential or anonymous sources, and no page here should be read as resting on one. In the narrow case of a matter of genuine public interest that could not be documented otherwise, the page would state plainly that the claim is unverifiable by the reader — and it still would not be used to establish routine technical rules.

Our verification method is described in How We Test. If you find a source on this site that is broken, outdated, or does not support the claim it is attached to, please report it through the Contact page.