---
yip: 0
title: YIP Purpose and Process
status: Final
type: Meta
author: metakovan
created: 2026-06-19
---

# YIP-0000: YIP Purpose and Process

A **YIP** (Yettagam Improvement Proposal) is the unit of change for the yettagam
schema. Every addition or revision to the published schema — a new yType, a new
version of an existing type, a meta-schema change — is proposed, reviewed, and
recorded as a YIP. YIPs are to yettagam what EIPs are to Ethereum: a durable,
numbered, public record of *what changed, why, and with what compatibility
impact*.

yettagam is the IP — the meta-design principle for organizing data. The schema
is published openly so anyone can implement it; the YIP process is how that open
schema evolves without breaking the applications that depend on it.

## What requires a YIP

- adding a new yType to the global schema
- publishing a new version of an existing yType
- changing the yType meta-schema or yObj template
- any change to `ytypes/index.json` that adds, versions, or re-points a type

A purely site-specific type that an application keeps to itself does **not**
require a YIP — it lives in that application, not in the global schema. A YIP is
for types that graduate to the shared, reusable schema.

## Ownership and licensing

A yType you create and keep inside your own application is **private intellectual
property, owned by the organization that created it**. It is not part of the open
yettagam schema, carries no obligation to be shared, and is licensed however its
owner chooses (by default, all rights reserved). The yObj library an organization
builds on top of these types is likewise theirs.

**Submitting a YIP is a deliberate, voluntary act of publication.** A type becomes
public only when its owner chooses to propose it as a YIP and the maintainer merges
it — there is no automatic graduation. On merge, that type is published into the
open, shared schema under its open license
([Apache 2.0](https://github.com/MetariumProject/yettagam-net-website/blob/main/LICENSE))
and may be implemented by anyone.

This boundary is the whole point: the yettagam *principle* (the meta-design for
organizing data) and the *published* schema are open; the private types and yObj
libraries each organization builds remain their own.

## YIP types

| type | for |
|------|-----|
| **Schema** | a new yType or a new version of one (the common case) |
| **Meta**   | the meta-schema, yObj template, or the YIP process itself |
| **Informational** | guidance/conventions with no normative schema change |

## Status lifecycle

```
Draft  ->  Review  ->  Last Call  ->  Final
                          \-> Withdrawn / Rejected
```

- **Draft** — opened as a pull request; the schema files are present and validate.
- **Review** — under maintainer review; discussion on the PR.
- **Last Call** — accepted in principle; final window for objections.
- **Final** — merged. The schema files are published at `yettagam.net` and the
  YIP is immutable. Superseding it requires a new YIP.
- **Withdrawn / Rejected** — closed without publishing.

The maintainer (currently [metakovan](https://metakovan.net), [onemai
foundation](https://onemai.net)) merges YIPs. Submitters open the PR; the
maintainer decides.

## Versioning and compatibility (the contract)

There are **two independent version axes** consumers must understand:

1. **Application version** — your app's own release. Yours to manage.
2. **yettagam schema version** — the version of the published schema your app is
   built against. This is the `version` field of
   [`ytypes/index.json`](https://yettagam.net/ytypes/index.json), bumped by each
   Final YIP that changes the published set.

The compatibility rule, enforced by the registry's *widening-only* gate:

- **Within a major version, every YIP is widening-only** — additive and
  backward-compatible. New types, new optional fields, new enum values, loosened
  constraints. An app pinned to schema `1.x` can safely adopt any `1.y` with
  `y ≥ x`, *at its own pace*.
- A change that could invalidate a previously-valid yObj — removing or renaming a
  field, narrowing a type or enum, adding a required field or `pattern`, tightening
  `minimum`/`maximum`, closing `additionalProperties`, or dropping a parent from
  `inherits_from` — is **breaking** and requires a **new major version** of that
  type (a new `{name}/{X+1}.0.0/` permalink). Old permalinks are immutable and
  remain served forever.

This is why a type can have many versions and never break anyone: `image/1.0.0`
is frozen; `image/1.1.0` only widens it; `image/2.0.0` is a deliberate, opt-in
break.

## How applications stay current

The schema is consumed **offline-first and pinned**: an application vendors a
snapshot (mirror) of the types it uses and records the schema version it is
pinned to. To stay current it **polls** the manifest and upgrades on its own
schedule:

```
GET https://yettagam.net/ytypes/index.json     # cheap, cacheable, CORS-open
```

Compare the manifest `version`. If a newer *same-major* version exists, the app
may refresh its mirror and adopt the new/updated types — a backward-compatible
upgrade it can take whenever it likes. A new *major* version is an explicit
migration the app opts into.

The renderer is the component that cares about schema version: it adapts its
handling to the schema version of the yObj it is given, which is how one renderer
can serve objects authored against several schema versions.

> A webhook/push notification on YIP merge is an optional convenience layer; the
> pull + version-pin model above is the normative, dependency-free baseline and
> should not be replaced by it.

## See also

- [YIP-template](yip-template.md) — start a new proposal here
- [yips/index.json](index.json) — machine-readable YIP index
- [/integration/](https://yettagam.net/integration/) — schema reference + validation
- [/agent-context/](https://yettagam.net/agent-context/) — machine-readable agent entry point