Research and review methodology

The publication workflow

1. Define the reader question. Each page starts with one primary search intent and a concrete reader outcome. Closely related questions may support the page; a second unrelated intent requires a different page.
2. Collect primary sources. Platform behavior is checked against the platform owner’s documentation. Provider data practices are attributed to the provider’s current documentation. General learning advice uses an original source when one is available.
3. Run a product check. App claims must be supported by the current source code, an observed current-build workflow, or both. A planned feature, old screenshot, or marketing phrase is not enough.
4. Record evidence and limitations. The draft separates what was observed from what was inferred, links its sources, and names conditions that can change the result.
5. Check the page as a reader would. The direct answer, headings, examples, links, screenshots, accessibility, structured data, and search metadata are checked together.
6. Require accountable human approval. Heni must approve the factual claims, product presentation, limitations, and final page before publication. A page is not described as reviewed by Heni until that approval actually happens.

Evidence types and boundaries

Primary documentation

Official Apple, provider, standards, or research documentation for claims about those systems.

Current app evidence

Inspected source code, a reproducible current-build check, and real screenshots when the visual state matters.

Bounded examples

Examples that explain a workflow without presenting one result as a general accuracy, speed, or quality benchmark.

Explicit unknowns

Account settings, provider behavior, legal choices, and live-store facts remain unverified until they are checked at the source.

What the process does not prove

Review cannot guarantee that an AI-generated summary is complete or accurate. Provider behavior and platform interfaces can change after a check. A code path proves what the inspected source is designed to do, not that every live request will succeed. The site therefore avoids unmeasured ranking, volume, speed, and accuracy claims.

The AI summary accuracy guide turns these boundaries into a practical claim-to-source checklist.

Corrections and update triggers

A page returns to review when the app changes, a primary source changes, a link stops supporting its claim, a limitation is discovered, or a reader provides reproducible evidence of an error. Material corrections update the affected claim, its evidence, and the page’s review date only after the correction has been checked.

The editorial policy defines claim and disclosure rules. The About page identifies the person accountable for final publication.