No hidden official status.
MonkeyCode Index is independently produced and is not a Chaitin property. Product support, release notes, security reporting, and definitive technical instructions belong to upstream channels.
METHODOLOGY · EDITORIAL POLICY · UPDATED 2026-07-10
Evidence before opinion. Context before recommendation.
MonkeyCode Index is an independent English-language research site. It is not operated by Chaitin, and it is not the official MonkeyCode website.
The editorial contract
What a reader should be able to verify.
A useful page makes it clear which statements come from the project, which conclusions come from us, and which questions remain unanswered until a team runs its own pilot.
Facts and interpretations are different objects.
“The project documents private deployment” is an upstream claim. “Private deployment fits teams with infrastructure ownership” is editorial interpretation. “This deployment is secure” would require environment-specific evidence we do not have.
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.
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.
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. Upstream remains authoritative after that date.
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.
Repository and license
Source code, README, release files, configuration, and the license establish the strongest public evidence for the open project.
Official documentation
Current installation, architecture, integration, and operations guidance—checked for version and date sensitivity.
Maintainer channels
Issues, releases, discussions, and announcements can clarify behavior but may describe plans, defects, or a specific version.
Editorial analysis
Our category maps, fit tests, checklists, and recommendations. Useful for decisions, but explicitly not upstream product claims.
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.
Current source base
Start upstream. Return upstream.
These links are authoritative for changing product details. This site adds decision context; it does not replace them.
S-01GitHub repository
Project source, README, releases, issues, and implementation history.
Open source ↗ S-02Official documentationCurrent deployment and product guidance from the upstream project.
Open source ↗ S-03AGPL-3.0 licenseThe license text, not our summary, controls legal obligations.
Open source ↗ S-04Hosted serviceThe upstream product surface; availability and behavior may change.
Open source ↗USE THE POLICY