Palworld Breeding Combination Discovery Log

Turn scattered breeding attempts into a reusable record of what you tested, what you observed, and what to try next.

What a breeding discovery log is for

Define the page as a recordkeeping tool rather than an authoritative combination database or another general breeding planner.

• Use the log when the immediate problem is remembering which parent pairs were tested and what followed.
• Treat each row as an observation tied to the version recorded at the time.
• Keep target planning and broad optimization on the related breeding-goal and starter-project guides.

Start with one discovery question

Give each attempt a bounded purpose before the player commits resources or time.

• Write the Pal or role being investigated without assuming a particular pair will produce it.
• State what the next attempt is intended to clarify.
• Separate the current question from optional qualities that can be evaluated later.

Create the minimum useful log fields

Provide a reusable template that distinguishes evidence, context, and interpretation.

• Record the game version, date, target, both parents, and observed result.
• Add a status field such as observed, referenced, or untested.
• Include a short note explaining why the pair was selected and what question remains.

Record results without overwriting history

Preserve an auditable sequence of observations and prevent memory-based conclusions.

• Add a new row after each completed attempt.
• Keep the original entry when a later observation differs; add context instead of silently replacing it.
• Use consistent parent labels so repeated pairs can be found quickly.

Choose the next bounded test

Convert the log into a decision aid without claiming unsupported breeding mechanics.

• Compare the latest observation with the question written before the attempt.
• Change only the input relevant to the next question when practical.
• Pause when the next test cannot be explained from the existing record.

Keep patch-sensitive claims labeled

Prevent observations from being presented as permanent or universal rules.

• Retain the version attached to every observation.
• Recheck important entries after a relevant breeding-system notice rather than assuming they still apply.
• Do not treat the supplied v1.0.3 notice as evidence of a breeding-combination change because its captured text does not identify one.

Decision checklist

• Write one breeding discovery question.
• Record the current game version.
• Enter both parents using consistent labels.
• Record the observed result without adding an inferred rule.
• Label the entry as observed, referenced, or untested.
• Append conflicting observations instead of deleting earlier rows.
• Choose one explainable next test or pause the project.

Worked example

Suppose your goal is to investigate a route toward Target T using breeding stock already available. Create an entry with the current version, Parent A, Parent B, and the result you actually observe. Mark that row as observed. If an outside reference suggests a different pair, add it as a separate referenced entry rather than merging it with your observation. For the next attempt, keep the target fixed, select the single input you want to reconsider, and write why that change would answer the next question. If the result differs from an earlier row, preserve both records and note the context instead of declaring a universal rule.

Common mistakes

• Recording a hoped-for target as though it were an observed result.
• Mixing firsthand observations with outside references under one status.
• Omitting the game version from an entry.
• Changing several parts of the plan without identifying the question being tested.
• Deleting a conflicting result instead of preserving both observations.

Related guides