Useful technical profiles. Clear evidence.

Scope and admission

We include infrastructure, builder tools and relevant applications whose primary function fits our four technical areas. Profiles need a traceable project identity and enough official evidence to explain their purpose and supported use. Official repositories and documentation are preferred; closed-source apps may qualify with official product material and publisher-identified store records.

Generic websites, unrelated consumer apps, news briefings, promotional pages and keyword matches do not qualify merely because they mention AI or crypto. Store descriptions are publisher claims and must be treated accordingly. Incomplete or out-of-scope candidates can be archived without appearing in the public directory.

What a useful profile contains

A profile should explain what the project does, tasks it supports, who can use it and the requirements relevant to that use. Stack, platforms, ecosystems, licensing, access conditions and limitations appear only when documented. Practical guides include supported prerequisites, steps and sources; we do not invent installation commands or successful outcomes.

Source checks and execution tests

Checking a repository, documentation page or store record is not the same as running a project. “Sources checked” identifies source review, not a security audit or performance guarantee. A source-based guide describes documented steps. Recipe execution reports record the tested version, environment, date, cases, results and limitations. Passing synthetic offline cases does not establish live-service behavior, production safety or that the full underlying project was tested.

Classification and identity

Each project has one canonical record and a primary technical placement. Infrastructure, builder tools and apps provide an additional discovery lens. Platform, language and ecosystem remain separate attributes. A repository, website, documentation set and app edition may be linked only when official evidence establishes that they belong to the same project.

Comparisons and editorial selection

Comparison candidates must share a documented task and a compatible project role. Sharing a category is insufficient. Comparisons explain the common use case and documented differences; they do not establish interchangeability or benchmark superiority. When no defensible match exists, we omit the comparison.

Editorial starting points highlight profiles with a clear purpose, supported use cases and source-based guides. They are separate from recent additions, are not paid placements and do not certify the software itself.

Evidence and uncertainty

Official sources and deterministic checks are preferred. Secondary sources may supply narrowly matched background context, but cannot replace official evidence for current capabilities or access conditions. Unsupported values remain unknown. A missing statement is not proof that a feature does not exist.

Automation, corrections and independence

Automated inspection and assisted drafting must pass identity, relevance, evidence and quality controls. Daily limits are ceilings, not publication targets. Failed candidates remain pending or are archived with a recoverable reason. Sensitive claims, ownership disputes and corrections require review. Inclusion cannot currently be purchased; future commercial relationships must be disclosed and cannot guarantee favourable coverage.

OpenViST Tools

Tools provide bounded, deterministic browser processing with visible requirements and limits. Their source, documentation and tests are published in the public repository. Test results support the tested version and cases, not exhaustive correctness. Tool inputs are not used as prompts or uploaded for processing. Reported defects are reviewed before a new version is released.

Sharing Journal text

OpenViST’s original Journal text is offered under CC BY 4.0, subject to the scope and exceptions in our Terms. Reuse may include translations and adaptations, including commercial use. Credit OpenViST and any separately required author attribution, link to the original article and licence, identify changes and do not imply endorsement. Images, third-party quotations and other excluded material need their own permission or applicable legal basis. See the reuse guide and attribution examples.

Journal standards

Articles should address concrete architecture choices, integrations, trade-offs and comparisons relevant to the directory, and link to the projects they discuss. Images must match the article context. Generic articles added only for volume do not meet this standard. Substantive corrections should be made transparently.

Admission before publication

Every new project needs a concrete purpose, at least two documented tasks, a source-based practical guide and a recorded editorial selection explaining its value to a reader. Classification alone does not authorize publication. Changes to the source, profile sections, guide or prepared article require a fresh selection.

Lists of links, resource directories and paper collections are research sources; we do not publish them as executable projects. A reusable software tool with its own documented workflow is evaluated on that workflow, regardless of its programming language or name.

Data-provider sources

Data providers may qualify as technical project listings when their documented tools or integrations support a concrete task. Official project sources establish identity, network, contract addresses and technical capabilities. Names and ticker symbols are not unique identifiers. Provider licences, attribution and API limits govern any data integration; OpenViST does not automatically import or republish provider datasets.

Automatic admission and updates

Automatic admission uses a versioned rule set, current primary-source evidence and the same identity, taxonomy, guide and quality checks required for publication. An AI classification alone cannot authorize publication. Unknown identities, unsupported claims, changed source documents and expired reviews remain pending. Automatic decisions are recorded separately from human editorial selection and execution tests.

Availability checks record whether a source can be reached. They do not refresh the factual review date. Changes to documentation are flagged for review; unchanged content is reused. Search and filtering use public records and do not make paid AI requests.

Project representation

Representatives can submit evidence and correction requests. Verification checks control of the listed website or access to the exact listed GitHub repository; it does not establish legal ownership or authority to speak for an organization. Requests are reviewed before approval and do not grant direct editing of independent profiles. Other hosted platforms use manual evidence review. Readers can report errors without representing the project.

Technical scope for blockchain and crypto

Wallet software, blockchain networks, protocols, developer tools and documented applications qualify through their practical function and official evidence. A ticker, token price or listed share alone is not a project admission criterion. We do not publish standalone coin or stock research profiles.

Learn lesson standards

Learn introduces practical foundations through explanations, worked examples, exercises and links to primary documentation. Each lesson states its intended environment and prerequisites. Examples and recorded checks support their stated scope; they do not imply that every operating system or VPS provider has been tested. Commands distinguish local and remote environments. Corrections are reviewed before an updated lesson is released.

Server-backed tool scope

The hosted Link Auditor makes bounded HTTP requests after website-control verification. It is separate from the deterministic local browser utilities described above. Its documentation distinguishes checked, unchecked, redirected and access-restricted URLs; it does not constitute a complete SEO or security audit.

Recipe standards

OpenViST prepares recipe drafts internally, including assisted generation and documented adaptations of existing examples. Each published recipe must describe a distinct useful task, language and version, inputs, requirements, sources, limitations and the tests actually performed. New generated scripts pass execution tests and editorial review before publication. Execution support and requirements are recorded for each recipe; results describe the exact tested language, version and scenarios. Browser previews do not run the downloaded scripts, and WordPress does not execute submitted recipe code. Readers may propose improvements; publication remains a separate controlled step.