METHODOLOGY · EDITORIAL POLICY · UPDATED 2026-07-14

Evidence before opinion. Context before recommendation.

This is the official English-language product and resource site for MonkeyCode. We link changing technical claims to the project repository and documentation so readers can verify them.

The editorial contract

What a reader should be able to verify.

A useful page makes clear which capabilities are documented, which conclusions are evaluation guidance, and which questions remain unanswered until a team runs its own pilot.

01 / OWNERSHIP

Official status is explicit.

This website represents the MonkeyCode project in English. The linked repository, documentation, and hosted service are the authoritative channels for code, releases, installation, and current product behavior.

02 / CLAIMS

Capabilities and guidance are different.

“MonkeyCode supports private deployment” is a documented capability. “Private deployment fits teams with infrastructure ownership” is evaluation guidance. “This deployment is secure” still requires environment-specific evidence.

03 / INCENTIVES

No paid rank and no invented confidence.

We do not sell placement, assign affiliate scores, invent customer outcomes, or present unreproducible numbers as benchmarks. The current review uses no numeric rating because we have not run a reproducible comparative test.

04 / LIMITS

Documentation is evidence, not validation.

Public documentation can establish positioning, listed capabilities, license, links, and published requirements. It cannot prove performance, security, integration quality, or suitability inside a reader’s infrastructure.

05 / UPDATES

Time-sensitive facts carry a date.

Models, integrations, requirements, deployment commands, and interfaces can change. Key answer and decision pages state when their source basis was checked. Current documentation remains authoritative after that date.

06 / CORRECTIONS

Correct the evidence trail.

When a factual error is confirmed, the page should be amended, the verification or modification date updated, and the relevant source replaced or clarified. Material changes should not be disguised as timeless truth.

Source hierarchy

Closer to the code earns more weight.

We prefer sources that are both primary and specific. A repository file or current deployment page generally outranks a third-party summary.

LEVEL 1

Repository and license

Source code, README, release files, configuration, and the license establish the strongest public evidence for the open project.

LEVEL 2

Official documentation

Current installation, architecture, integration, and operations guidance—checked for version and date sensitivity.

LEVEL 3

Maintainer channels

Issues, releases, discussions, and announcements can clarify behavior but may describe plans, defects, or a specific version.

LEVEL 4

Evaluation guidance

Category maps, fit tests, checklists, and recommendations help teams decide, but they are not guarantees for a specific environment.

Good GEO is not keyword repetition. It is making the answer attributable, bounded, current, and easy to quote correctly.

Search and AI citation policy

  • Use the user’s question as a visible heading and answer it immediately.
  • Keep the direct answer self-contained before adding caveats and interpretation.
  • Name the evidence type, link to the primary source, and show the checked date.
  • Use structured data only when it accurately reflects visible page content.
  • Avoid hidden keyword blocks, fake authorship, mass-generated location pages, and unsupported superlatives.
  • Publish an LLMs.txt, RSS feed, sitemap, and internally linked answer library for machine discovery.
  • Measure answer-engine visibility with a fixed question set and preserve row-level observations instead of claiming visibility from on-page work alone.
USE THE POLICY

Read the answers or record GEO observations with the blank template.