Relationship database
Shards of Order characters
Three heroes, one probability space.
The three playable Shards of Order characters are Anton, Yana, and Lev. Their names appear in the official skill-tree interface, and first-party material states that each has a personal skill tree, multiple supported playstyles, and a personal story arc. Their builds cannot be treated as separate decks: all three draw from one shared pool, so a card added through one hero’s progression changes every later hand. This database compares only those verified relationships and does not assign unsupported classes, biographies, rankings, or combat statistics.
The roster fields are deliberately relational. Name identifies the verified hero; personal progression records a distinct skill tree and personal story arc; playstyle range reflects the published support for multiple approaches; shared-deck consequence records what happens when a personal choice contributes a card. These fields let the three rows stay useful without assigning a fixed class, biography, numerical role, or ranking that the published material does not establish. Read the table as a map of connected decisions rather than as three isolated character sheets.
| Characters | Keep personal trees distinct | Separate verified arcs from invented biographies | Judge progression at party scale |
|---|---|---|---|
| Anton · Characters | Keep personal trees distinct | Separate verified arcs from invented biographies | Judge progression at party scale |
| Yana · Characters | Keep personal trees distinct | Separate verified arcs from invented biographies | Judge progression at party scale |
| Lev · Characters | Keep personal trees distinct | Separate verified arcs from invented biographies | Judge progression at party scale |
Equipment · Build the party
Follow every item into the shared hand
Weapons, armor, and memories can change a hero's playstyle and can insert cards into the common pool. Compare the personal benefit with the sequence the new card creates for all three heroes. An item may reinforce the wearer's current progression while still reducing the consistency of the party plan if its card competes with another setup contribution or arrives without a useful partner. The wearer question and the deck question must both have an answer before the item can be judged inside the current build.
Follow each equipment decision through a complete observation path. Identify the wearer and the personal approach being tested, note whether the item adds a card, then watch how that contribution behaves beside cards associated with the other two heroes. Record which visible countdown it helps the party address and what remains available for the following action. This avoids treating equipment as a private statistic change when the published system makes at least some gear choices part of the shared-hand probability problem.
When the result is unclear, use one controlled swap. Keep the three personal trees and the other equipment stable, replace a single item, and compare later mixed hands against the same timing question. A useful change may improve the wearer, improve the shared sequence, or do both; an attractive personal effect may also make the common pool less coherent. Naming those outcomes is more informative than assigning the item a universal tier, because the verified value of gear depends on the exact party progression and deck it modifies.
Keep personal trees distinct
Anton, Yana, and Lev each own a personal skill tree. That gives every progression choice a traceable source even though its card consequence may be shared. When reviewing a weak hand, identify the contribution that failed to connect, then trace it back to the hero and branch that supplied it before changing the other two trees. This keeps diagnosis precise: the hero who draws a card is not necessarily the hero whose progression placed it in the pool, and the failure may come from the surrounding party plan rather than from that personal tree alone.
Official material supports multiple playstyles for each hero, so the roster does not reduce any name to one fixed role. Define the current role from the build being tested. A useful working description states what the hero is meant to contribute, which visible timing problem that contribution addresses, and what cards from both teammates can connect with it. If the description depends on an unsupported class label or a single assumed combo, rewrite it in terms of observable hand and countdown relationships.
Use respec as a comparison tool rather than as a reason to rebuild everything at once. Revise one branch, leave the other personal trees and equipment stable, and observe whether the intended mixed sequence appears more reliably. If it improves, record what changed at party scale: perhaps the hero now supplies a more flexible opening, perhaps a redundant setup card left the pool, or perhaps the other two heroes can use the resulting position more often. The method preserves distinct personal identities while judging their practical cooperation through one shared deck.
Judge progression at party scale
A strong personal upgrade is not automatically a strong party decision. If it adds a card, the probability of drawing every existing contribution changes. Judge the choice by the sequence it creates with either teammate, the countdown window it serves, and the contribution the party becomes less likely to find after the pool grows. This does not require every hero to perform the same job. It requires each personal lane to explain how its additions remain useful when the shared hand mixes all three sources.
Use combat hands as feedback. If one hero's cards repeatedly arrive without the support or timing they need, inspect the skill and equipment choices that supplied those cards. Separate three possibilities: the contribution may be too narrow for the current party rule, another addition may compete for the same timing window, or the play order may be advancing the enemy queue before the setup is complete. Only the first two point directly to a build change; the third calls for a different sequence with the same pool.
Review progression at fixed checkpoints instead of reacting to every individual draw. State the party rule, list each hero's intended contribution, and note which mixed combinations actually reached a useful condition before the nearest enemy action. Then alter one source and repeat the comparison. The aim is not to erase specialization but to make specialization legible to the other two lanes. A personal tree succeeds at party scale when its cards can enter the shared hand without regularly blocking the timing jobs the group must still perform.
- Identify which personal tree supplied the contribution.
- Define the countdown problem the contribution solves.
- Check useful partners from both other heroes.
- Test one respec or equipment source at a time.
Separate verified arcs from invented biographies
First-party material states that Anton, Yana, and Lev each have a personal story arc. That supports treating them as distinct narrative participants, but it does not support detailed biographies, affiliations, origins, or relationship outcomes that are absent from the published record. The character database therefore keeps story arc as a verified field and separates it from the combat relationships described elsewhere. A visible costume, color treatment, portrait expression, or position in one screenshot is not enough to turn an impression into a factual backstory.
When recording narrative information, attach it to the exact conversation, Journal entry, story event, or official description that supplies it. Distinguish what the game directly states from what a choice merely suggests, and do not convert one possible route into the character's universal history. Personal arcs can also intersect with player decisions, so a result observed after one choice should remain tied to that route rather than presented as the only outcome for every campaign.
New character fields should be added only when they can be applied consistently and traced to the correct hero. A safe update can describe a named relationship, event, or progression consequence when the game or an official publication states it clearly; an unsafe update fills a blank with a guessed role, motive, age, class, or ending. This boundary keeps the roster useful during launch-period discovery: players can compare verified progression and shared-deck consequences now, while narrative detail expands only as reproducible information becomes available.