Program Terms

Version 1.0. Published 29 July 2026.

These are the working rules of the contribution program. They sit alongside the Contributor Agreement, which covers rights, and the Content Policy, which covers what may be written.

They live in a separate document because they change more often than a contract should. Where they conflict with the Agreement, the Agreement wins.

Submitting

What we accept right now

Your own original fragments. That is the whole list at launch, and it is deliberate: it keeps the first stretch of the program simple while the process finds its feet.

That is less limiting than it sounds, because you can already build on other people’s work without touching their files. A fragment gated on played: their_fragment_id only appears for players who saw theirs. No permission needed, nothing of theirs altered, and it is the way we would rather people collaborated anyway.

What unlocks later

Additions, a new choice or branch inside someone else’s fragment, unlock once you have one fragment shipped. Not seniority, just evidence that you have been through the process once and met the people reviewing.

Rewrites, replacing someone’s words, come later still and need that author’s explicit agreement. See section 14 of the Agreement.

How many at once

Ten open submissions per writer. Enough that nobody is throttled, low enough that the queue cannot be flooded.

Review runs round-robin across writers rather than strictly oldest-first, so one prolific contributor cannot crowd everyone else out.

Turnaround

We aim for a first response within seven days. That means a real response: accepted, declined with reasons, or specific changes requested. Not an acknowledgement.

When the project is on a break, a notice says so and submissions are paused rather than silently queued. We would rather tell you nothing is happening than let you wonder.

Review

Every submission is checked automatically first, for whether it parses and builds. That check is about format, not quality. Passing it means the file works, not that the fragment is good.

Then people read it. What they are looking for is in the Style Guide: does it fit the game’s voice, do the stats express personality rather than power, is a gated path worth reading from both sides.

Declines cite a reason, and where the reason is a rule, they cite the section. Declines are sent privately. There is no public wall of rejected work.

Credit

Your handle goes in the fragment’s author: line and stays there. Credit appears in the Fragment Library, and wherever the game lists contributors.

Contribution kinds

The ledger records what each person did, using these kinds:

Kind	Meaning
`created`	Wrote the fragment. Every shipped fragment has exactly one.
`choice-added`	Added a choice, branch or subscene to someone else’s fragment.
`rewrite`	Replaced the text of an existing fragment, with its author’s agreement.
`edit`	Made or drafted a maintenance edit: fixes, balance, continuity, format.
`world-element-used`	Introduced a character, place or event that another fragment then used materially.

The ledger records facts only. There are no weights or values in it, and there never will be. What a kind is worth is a question for the payment schedule, published separately and applied afterwards, so that accepting your fragment is never a negotiation about what it is worth.

Crossover credit

When a fragment makes material use of a character, place or event that someone else introduced, the originator gets a world-element-used entry.

The rules around it, so the scheme stays sane:

It is recorded when a submission is accepted, by us, not declared in the .frag file. Writers never have to think about it.
Material use only. A scene with the character counts. A passing mention does not.
Project-owned elements carry no credit. The family, the town, the recurring furniture of the game belong to Wyrdwright and are free for everyone.
It never cascades. If a crossover introduces its own new character and a third fragment uses that, only that character’s originator is credited. Credit does not stack through chains.
It is capped, both as a small share of any one fragment and in total per person, so that inventing characters is never a better strategy than writing fragments.
Withdrawal does not end it. If your element is still in use, the record continues.

Whoever writes the crossover is its author, and gets the created entry. The originator’s entry is additional, never a division of the writer’s.

Taking your name off

You can have your name withheld from any fragment, or from all of them, at any time and without giving a reason. Most often this comes up after an edit you disagree with.

It changes what is displayed and nothing else. Your ledger entry stays as it is, and if revenue share is ever active, withholding your name does not reduce it by a cent.

Editing

We maintain fragments after they ship: fixing errors, keeping continuity, rebalancing stats, adapting to format changes, migrating to newer .frag syntax. Section 10 of the Agreement lists what that covers.

A substantial edit is one that changes what happens in the fragment, what a choice leads to, or the voice it is written in. Working thresholds:

rewriting a paragraph so it says something different: substantial;
changing which stat a choice checks, or flipping an outcome: substantial;
changing the tone of a scene: substantial;
fixing typos, formatting, syntax migration: not substantial;
adjusting a stat effect by a point or two for balance: not substantial;
renaming a variable, splitting a file, re-sequencing: not substantial.

When we make a substantial edit, we tell you and you can ask for your name off the result. When we make a routine one, we just make it.

If another contributor drafted the edit, they get an edit entry. Your created entry and your author: line do not move.

Rewrite etiquette

These are community norms, not contract terms. The Agreement says a rewrite needs the author’s yes, and that is the rule. What follows is how to be decent about it.

Ask the author directly, and say what you think is wrong and what you would do. Give them real time to answer, and take silence as silence rather than as permission. If they say no, that is the end of the rewrite, and it is not something to relitigate in public. It does not follow that the fragment keeps shipping: that is a separate call, and the Agreement says so openly in section 20.

Before proposing a rewrite, consider whether you actually want one. A linked fragment lets you tell your version of the story without touching theirs. An addition lets you fix a gap without replacing a voice. Most of the time one of those is the better idea anyway.

If a rewrite happens, both of you are credited: their created entry stays, you get rewrite.

When a fragment stops shipping

You withdraw it

Write to us and your fragment stops shipping, in the next release and within 30 days at the latest. No reason needed.

What happens around it:

Your ledger entry stays, marked with the date. Your authorship record survives.
The fragment’s id is retired, so other people’s fragments that referred to it still build; that reference simply can never be satisfied again by a new player.
Any addition another contributor wrote inside your fragment goes with it, since it is built on your text. They are told, and their entry stays.
Copies already distributed stay distributed. Withdrawal is about future builds.

We unlist it

Wyrdwright is a curated game, so we may take a fragment out of future builds at our discretion. Common reasons, not an exhaustive list:

It breaks the Content Policy.
It draws a credible claim that it infringes someone’s rights.
It cannot be made to build or play.
It contradicts the game around it in a way editing cannot fix.
It no longer fits where the game is going.
A phase or theme has grown lopsided and needs thinning.
It falls below the standard the game has since set.
A platform we distribute through requires it.

We say which reason applies, in the fragment’s thread, and you can contest it and get an answer.

That discretion includes the case where we wanted a fragment rewritten and its author would rather it stayed as it is. We may stop shipping it instead. Said plainly here rather than left for anyone to discover later.

What does not change is that nobody alters your words without your agreement. Declining a rewrite means no rewritten version gets published, and that holds whatever we decide about shipping the original.

Unlisting leaves your credit and anything already earned untouched. A fragment that is not shipping does stop earning going forward.

The one case where history is rewritten

Withdrawal and unlisting both leave the repository’s history intact, deliberately: the record is what proves who wrote what.

There is a narrow exception, and it exists because some claims are not ours to refuse. If a legal demand arrives, or if someone who never agreed to anything finds their personal data in a fragment, or if content is unlawful to hold, we will remove it from history as well as from the game. That is a last resort with its own procedure, decided by the project lead, and it is not available to an author who has simply changed their mind. Withdrawal is what that is for.

What happens to fragments that depended on it

This is our problem to solve, not a reason to make anyone wait.

When something is retired, we check what pointed at it. If a replacement fragment covers the same ground, we walk each dependent one at a time: repoint it where the replacement genuinely serves the same beat, fix or retire it where it does not. We do not repoint everything automatically, because a dependent that leaned on specifics of the original would then read as a non-sequitur.

Variables are the harder case. If the retired fragment was the only thing that set a variable another fragment reads, that fragment’s branches go dead no matter what we do about played: hooks. We check for it by hand today, and the cross-tree validator will catch it when it lands.

Payment

There is no revenue share yet. The game is free and nothing is sold.

What we can say now:

Attribution is guaranteed from day one.
Revenue share activates at a stated threshold, which we will name when we get closer to it.
The full schedule will be published here before the first payment, not after. What each contribution kind is worth, how the pool is calculated, what counts as revenue, what the caps are.

We are deliberately not publishing a percentage yet, because the calculation to determine it doesn’t exist yet. When there is a number, it will be a real one, with the arithmetic shown.

What we have already committed to, in section 22 of the Agreement: at least 30 days’ notice before any change to the schedule; a payment period already calculated is never recalculated, so earned money stays earned; each period is calculated under the schedule in force during it; no change is aimed at an individual; and work contributed before revenue share existed is covered by the schedule in force when it starts. Contributing early does not mean contributing for nothing.

What nobody can promise is that a given fragment keeps earning the same amount in future periods. The schedule is relative, so adding a new contribution kind and giving it a value makes every existing kind a smaller share of the same pool, and the corpus keeps growing, so more work shares that pool over time. Both of those push individual earnings down without anyone behaving badly. We would rather say so here than imply a floor that does not exist.

Once anything is sold, every contributor gets a yearly report on how their work was used and what it earned.

Reserved: how the game chooses what you see

Not active yet. When ratings and rating-weighted selection arrive, this section will publish the parameters: the bounds within which ratings can shift how often a fragment is chosen, the floor that guarantees new fragments get seen, and the tag diversity rules that still apply on top. We publish the parameters because you should be able to understand why your fragment does or does not come up.

Reserved: the payment schedule

Not active yet. When it exists it will carry: the value of each contribution kind, how a module’s creator pool is calculated, what net revenue means for each channel we sell through, any cap on rating-driven bonuses, the minimum number of raters before ratings count for anything, the payment threshold and cadence, and the window for disputing a ledger entry.

Correcting the record

If your contribution is recorded wrongly or is missing, tell us and we will fix it. Bring the thread or the pull request if you have it.

We will publish a dispute window when the payment schedule lands, so that entries become final at a known point rather than being reopenable forever.

Changes to these terms

Changes are announced before they take effect, and the changelog says what changed.

Because these are the operating rules rather than the contract, most changes take effect quickly. The exception is anything touching payment, which follows the notice and no-retroactive-reduction rules in section 22 of the Agreement.

Changelog

Version 1.0, 29 July 2026. First published version.