AI sucks. AI is great. I think that AI simply doesn't know its place. SYNTH tries to solve this, creating a "novel" system of classifying whether a project is vibe coded and _receives_ AI generated…

A developer has proposed SYNTH, a standardized system for classifying how much AI-generated code a project contains and accepts. The system uses a 0-4 scale (SYNTH-0 for hand-made to SYNTH-4 for autonomous) plus assurance tags like REVIEWED and TESTED to indicate code quality practices.

Version: 1.0.0 Status: Draft for community adoption SYNTH tries to answer one question about a repo in one line: how much of this code came from an AI and what does this project actually accept? It lives as a single file in the repo root plus a badge in the README if you want one. SYNTH is a short answer to a question people keep asking anyway: how synthetic is this codebase and what's the project's stance on that? SYNTH-0 means hand-made, no AI-generated code accepted. SYNTH-4 means the opposite end: prompt-directed, AI content welcome everywhere. Everything in between is just a declared position, and none of the levels judge quality, they're just an honest description of how the thing got built. Each level covers two things at once: how the code came to exist and what the project will accept going forward. | Level | Name | Provenance | Policy what the repo accepts | |---|---|---|---| SYNTH-0 | Hand-made | Written by humans. No AI-generated code has been committed. | AI-generated code isn't accepted. Contributions containing it get rejected. | SYNTH-1 | Augmented | Humans wrote most of it; AI helped with completion, refactoring and debugging. Every line was accepted by a person. | AI assistance is fine for editing and completion, but a human has to write or accept every change. | SYNTH-2 | Woven | AI generated standalone snippets or modules; a human chose, integrated and understood each one. | AI-generated code is fine once a human has reviewed it and understands what it's doing. | SYNTH-3 | Co-authored | AI generated most of the code from human direction; a human reviewed it before it shipped. | AI-authored code counts as a first-class contribution, as long as a human reviews it before commit. | SYNTH-4 | Autonomous | Code was produced and committed from prompts, with little to no human review. | AI-generated content is accepted throughout, including unreviewed. Treat the repo accordingly. | This runs independently of the level above and it always has to be stated. If nothing was checked, say so, that's still useful information. | Tag | Meaning | |---|---| REVIEWED | A human read the diff before it shipped. | TESTED | Passing automated tests cover the code. | SECURITY-REVIEWED | A human did a security pass over it. | DOCS-REVIEWED | Public-facing docs were checked for accuracy. | UNREVIEWED | No meaningful human review happened. | EXPERIMENTAL | Prototype or toy code, not meant for production. | A declaration is just a level plus one or more assurance tags. SYNTH-1 · REVIEWED · TESTED — light AI help, well vetted. High trust. SYNTH-3 · REVIEWED · TESTED — mostly AI-authored, but reviewed and tested. Moderate trust. SYNTH-4 · UNREVIEWED — prompt-driven and unreviewed. Proceed carefully. Note that SYNTH-3 · REVIEWED · TESTED is more trustworthy than SYNTH-1 · UNREVIEWED . More synthetic doesn't automatically mean less trustworthy, assurance is what actually separates them. Colors run green to red across the levels cause who doesn't like a cool badge? . Assurance is shown as text not color, since it's a separate axis and shouldn't be flattened into the same scale. | Level | Badge | |---|---| SYNTH-0 | | SYNTH-1 | | SYNTH-2 | | SYNTH-3 | | SYNTH-4 | synth https://img.shields.io/badge/synth-SYNTH--3%20Co--authored-orange assurance https://img.shields.io/badge/assurance-REVIEWED%20%C2%B7%20TESTED-blue AI disclosure synth https://img.shields.io/badge/synth-SYNTH--3%20Co--authored-orange ./SYNTH assurance https://img.shields.io/badge/assurance-REVIEWED%20%C2%B7%20TESTED-blue ./SYNTH See the SYNTH ./SYNTH file for this project's AI-content policy and provenance. This is the one thing a maintainer actually has to write and it's one line. Drop a file named SYNTH no extension in the repo root, formatted like this: <level · <assurance tag · <assurance tag ... SYNTH-3 · REVIEWED · TESTED That's really all it takes. The level itself functions as the repo's AI-content policy see the table in §2 and the tags say what's been checked, so anyone landing on the repo gets both the stance and the trust signal in a single glance. If you want to note the tooling used or leave a short comment, add a second line starting with : SYNTH-3 · REVIEWED · TESTED agent-authored; integration tests added by hand The first line is the declaration and the only required part. A repo doesn't have to be uniform. The root SYNTH file states the dominant level and anything that deviates from it can be flagged with a one-line marker at the top of a file, or its own SYNTH file in a subdirectory. synth: SYNTH-4 / UNREVIEWED // synth: SYNTH-1 / REVIEWED // synth: SYNTH-2 / TESTED Dropping a SYNTH file into a subdirectory overrides the root declaration but only for that subtree. Useful for something like a prototypes/ folder marked SYNTH-4 · EXPERIMENTAL while the rest of the repo stays at SYNTH-1 · REVIEWED . A SYNTH declaration is a statement about provenance. It isn't a guarantee of safety or fitness for any particular purpose. User responsibility: it's on the people using or consuming a repo to actually look at the declared level and assurance tags before they build on it or run it. A higher synthetic level SYNTH-4 , say or a missing assurance tag UNREVIEWED , EXPERIMENTAL is a signal of real risk, and if you choose to run or deploy the code anyway, that's on you. Maintainer disclaimers: SYNTH doesn't override the usual open-source license disclaimers. An MIT license, for instance, still hands you the code "AS IS," no warranty attached. Maintainers use SYNTH for transparency, not to take on legal liability for whatever an AI generated or however the code behaves. Model providers: the tools and model providers used to generate code aren't responsible for how that code gets declared, merged or used afterward, that responsibility stays with the repo. A declaration states a fact from the contributor, it doesn't guarantee quality. - You typed it yourself and AI only answered conceptual questions → SYNTH-0 - You wrote it, AI filled in completions and refactors you accepted line by line → SYNTH-1 - AI wrote some functions or modules and you read them and wired them in → SYNTH-2 - An agent wrote most of it from your direction and you reviewed the diff → SYNTH-3 - You prompted it, it committed, and you didn't really read it → SYNTH-4 If you're not sure which way to round, disclose more synthetic involvement rather than less, and reach for UNREVIEWED or EXPERIMENTAL instead of overclaiming assurance you don't actually have. This spec follows semver. What each level means stays stable within a major version. The spec version currently 1.0.0 lives in this document, not the one-line repo file, that way the repo's own declaration stays short.