After a character evolves in MakoBits, check the Mako Archive record first. Then compare the character’s profile, room, scenes, items, abilities and relationships with what you saw before. Mark every area as changed, unchanged or not verifiable. MakoBits connects discoveries to systems beyond the merge board, but that does not mean every evolution changes every system. If you cannot see a difference or did not record the earlier state, do not infer an unlock. Note the uncertainty, keep the current state as a baseline and continue playing.
Use the RECAP post-evolution audit
RECAP is a five-step framework for turning a moment of discovery into a repeatable check. It separates what you can observe from what you might expect.
- R — Record the trigger. Note which character evolved and when you noticed it. Do not add a cause, reward or unlock condition unless the game shows it directly.
- E — Examine the record. Open the character’s Mako Archive record. Check only the fields visible to you rather than assuming that every possible field must be present.
- C — Compare connected areas. Review the profile, room, scenes, items, abilities and relationships. Use the same order every time so none is skipped.
- A — Assign an evidence state. Label each check
changed,unchangedornot verifiable. A visible new presence, detail or connection can count as changed. A missing before-state means a comparison is not verifiable. - P — Proceed on one finding. If you find a change, inspect that area more closely. If nothing can be verified, preserve your notes and return to play rather than searching indefinitely for a predetermined outcome.
The aim is not to prove that an evolution must have changed something. It is to find any visible difference while keeping uncertainty explicit. That distinction prevents “I noticed this afterwards” from becoming “this evolution always causes this”.
The reusable before-and-after audit sheet
Copy this table into a note. The “What to inspect” entries are prompts, not promises that a given evolution will affect those areas.
| Area | What to inspect | Before state | After state | Result | Next action |
|---|---|---|---|---|---|
| Mako Archive record | Visible record and any displayed details | ___ | ___ | Changed / unchanged / not verifiable | Read any newly visible detail |
| Profile | Visible progress or character information | ___ | ___ | Changed / unchanged / not verifiable | Note the precise difference |
| Room | Whether a new or altered presence is visible | ___ | ___ | Changed / unchanged / not verifiable | Inspect the visible change |
| Scenes | Whether available scene content differs from the before note | ___ | ___ | Changed / unchanged / not verifiable | Review only what is available |
| Items | Visible collectible or item differences | ___ | ___ | Changed / unchanged / not verifiable | Record any new item exactly as shown |
| Abilities | Visible ability information | ___ | ___ | Changed / unchanged / not verifiable | Compare wording or state if visible |
| Relationships | Visible friend, rival or other connection information | ___ | ___ | Changed / unchanged / not verifiable | Follow a newly visible connection, if any |
Three rules keep the sheet honest:
- Describe, do not interpret. “A new item is visible” is stronger than “this evolution always awards an item”.
- Separate unchanged from not verifiable. If you did not inspect an area beforehand, you do not have a baseline.
- Audit one evolution at a time. If several evolutions or other progression events occur between checks, record the difference but mark its cause as unknown.
The audit is most useful when the before and after notes use the same level of detail. “Room checked” is too vague. “Character not visible in room” gives you a state that can be compared later.
Example: auditing one newly discovered record
This is an illustrative walkthrough of the method, not a claim about a particular character or a guaranteed outcome.
A player sees a character evolve and opens the Mako Archive. They can see a record that was not on their before list, so they write: “Archive record — changed.” They copy a short description of the details they can directly see. They do not fill gaps from memory or add fields they expected to find.
They then check the profile. Because they did not prepare a before note for it, they mark the result “not verifiable”. This is not a failed check; it is the correct label for missing baseline evidence. The current profile becomes their baseline for a later comparison.
Next, they inspect the room. Their before note was “no visible presence for this character”. If they can now directly see a presence there, they mark the room “changed”. If they cannot see a difference, they mark it “unchanged”, provided the same room state is being compared. This example deliberately does not predetermine which result they will find.
The player repeats the process for scenes, items, abilities and relationships. Suppose no before notes exist for those areas. All four are marked “not verifiable”. The completed audit therefore has one confirmed Archive change, a conditional room result based on observation, and several unverified rows. It does not conclude that the unverified systems changed or stayed the same.
The next time a character evolves, the player will have a baseline. That turns the first audit from a hunt for an answer into preparation for a stronger comparison.
Implementation: a quick check and a deeper audit
You do not need to complete the full sheet after every evolution. Use two levels.
The quick check
- Identify the character. Write the name or another unambiguous identifier visible to you.
- Open the Mako Archive. Confirm whether a newly visible record or record detail is present.
- Check the room and profile. These are direct next checks identified in the public game guidance.
- Write one evidence sentence. For example: “Archive changed; room unchanged; profile not verifiable.”
- Resume play. Run the deeper audit only if you want to trace the discovery further.
The deeper audit
- Complete all seven rows in the audit sheet.
- For each row, decide whether a real before-state exists. If not, use
not verifiable. - For each
changedrow, describe only what can be seen: a record, presence, item, ability detail or connection. - If several progression events occurred between checks, record the visible change but set its cause to
unknown. - Pick one next action: read the record, inspect the changed area, follow a visible connection or resume merging.
To prepare for the next evolution, make a lightweight baseline now. Note the last Archive record you saw, the character’s current visible profile details and whether the character is visible in the room. For a complete baseline, add the remaining four areas. Consistent, short notes are more useful than detailed notes taken only occasionally.
Decide what to do next
Use the strongest observation in your sheet rather than the result you hoped to find.
| What you found | What it supports | Best next step |
|---|---|---|
| An Archive record or visible record detail changed | The record difference is directly observable | Read the new detail, then check any connection it names |
| One wider-world area changed | That area differs from your baseline | Inspect that area; do not generalise the result to every other area |
| An area was checked and is visibly unchanged | No difference was observed there in this comparison | Stop checking that area for this audit |
| The before-state is missing | No before-and-after claim can be supported | Mark not verifiable and use the current state as a baseline |
| No row changed | None of the checked areas differed from your baseline | Resume play; do not infer that something went wrong |
If you need a refresher on how the board, Archive and wider world fit together, use the MakoBits game overview as the verified starting point.
Limitations
This protocol organises observations; it cannot establish an unpublished unlock rule. The supplied public information confirms that MakoBits connects discoveries with the Mako Archive, profiles, rooms, scenes, items, abilities and relationships. It does not specify the exact change caused by any particular evolution.
Accordingly:
- An evolution may not alter every area. An unchanged row is a valid result.
- A change noticed without a baseline cannot be timed to the evolution with confidence.
- If other progression occurred between checks, the audit can establish a difference but not necessarily its cause.
- Exact unlock conditions, specific rewards, interface behaviour and individual evolution outcomes are not documented in the supplied source, so this guide does not assert them.
- The audit depends on what you can directly observe. An unclear or unavailable state should be recorded as not verifiable, not treated as evidence of an unlock.
The framework is deliberately conservative. It may leave more blanks than a guess-based checklist, but those blanks make later comparisons more dependable.
FAQ
What should I check first after a character evolves in MakoBits?
Check the Mako Archive record first. Then compare the profile, room, scenes, items, abilities and relationships with a before-state if you have one.
Does every evolution change the room, profile and relationships?
The supplied public information does not support that conclusion. These are connected systems worth inspecting, not a guaranteed list of changes for every evolution.
What if I forgot to note the before-state?
Mark the area “not verifiable”. Describe its current state so it can serve as your baseline next time. Do not relabel it “unchanged”.
Can I conclude that an evolution caused a change if I see it afterwards?
Only when you have a trustworthy before-state and no other relevant progression occurred between the two checks. Otherwise, you can verify that the state differs but not which event caused the difference.
Should I keep checking if nothing looks different?
No. If you completed the audit against a real baseline and found no visible change, record that result and resume play. The absence of a visible difference is not proof that something went wrong.