Process decision learning
Keep assumptions and source conflicts visible until they are resolved
An assumption and conflict register records an unresolved premise, ambiguity or source disagreement with its evidence, operational effect, temporary handling and resolution owner. It prevents an interpretation from becoming hidden project truth.
Use it when sources are incomplete, terms have different meanings or authorities appear to disagree. Make supported progress where possible while keeping the unresolved dependency and its consequences explicit.
Read the worked uncertainty register
Name the uncertainty before choosing a working action
An assumption fills a missing premise provisionally. An ambiguity permits more than one interpretation. A source conflict contains incompatible statements about the same subject and scope. These need different resolution paths; none should disappear into confident prose or an unexplained default.
An absent fact needs evidence
If the target content type, product version or applicable market is missing, record what is unknown and which decision depends on it. A familiar pattern or convenient setting can be a hypothesis, but it is not a supplied fact.
An ambiguity needs a bounded interpretation
A request for “custom post templates” can mean different content types or a template used by an existing type. Record the plausible meanings and the evidence needed to choose. Prepare unaffected content or a configurable package when useful, while leaving the unresolved consequential action explicit.
A conflict needs a scope comparison
Two statements are not necessarily incompatible if they concern different versions, markets or effective periods. Compare those qualifiers first. If the contradiction remains, retain supporting and opposing sources, their authority and the responsible owner’s unresolved decision.
A working decision is not new truth
Choose the action that needs the fewest unsupported premises and remains valid within the project’s authority and consequences. Reversibility helps, but it does not justify publishing an unsupported claim or making an external change outside the agreed scope. Keep unaffected work moving when its inputs remain sound.
Match the unresolved point to its handling and resolution
These hypothetical cases use invented project details and source records. They illustrate how to keep a temporary decision inspectable; they do not report a real importer setting, source conflict or resolution.
| Statement and type | Operational effect | Temporary handling | Resolution evidence and owner |
|---|---|---|---|
| Ambiguity: a request says “custom post templates” without identifying post, page or an installed custom type. | The importer’s target type can change route behavior and which existing records it touches. | Prepare the content and package specification without silently hardcoding the unresolved target. In the real importer, make the target explicit and verify it before creating or overwriting records. | Site/content owner confirms the installed target type and intended routes. Record the accepted setting and the check that prevents the package from applying it to the wrong scope. |
| Assumption: two product records have similar names, but their stable identities or versions are missing. | A comparison, merged record or graph relationship could join different products. | Keep the records separate and label the provisional match as unresolved. Work on independent fields only when their support does not require the missing identity. | Product/source owner supplies distinguishing identifiers and applicable versions. Recheck dependent claims and relationships after the identity is settled. |
| Conflict: source S1 and source S2 state different policy terms for what appears to be the same scope. | A current public claim or release decision could rely on the wrong term. | Retain both statements and hold the affected claim while the scope and controlling source are checked. Do not select the easier answer or assume the newest timestamp wins. | Policy/source owner resolves authority, version and effective period, or keeps the dependency open with the evidence still needed. |
| Apparent conflict: two price statements differ, but one may describe another market or period. | A universal price claim would erase a potentially valid qualifier. | Preserve each statement with its source and qualifiers. Do not average the amounts or turn a scoped price into a universal one. | Offer owner confirms the market, currency, period and relevant product or plan. If both remain valid in distinct scopes, record that resolution and correct the dependent wording. |
In the publishing case, making the target explicit is a requirement for the technical setup, not an interactive control supplied by this article. A conservative default can be appropriate only when its scope and effects are already supported. A neutral preparation state is preferable when every external target choice would introduce an unsupported assumption.
Keep the evidence basis and operational effect together
Record uncertainty when it first appears. The register should show the exact statement, its sources, the work it affects and the condition that will resolve it. Private notes and memory cannot reliably carry that boundary across contributors or later revisions.
- Statement and type Write the unresolved premise, ambiguity or conflicting assertions without presenting them as established facts. Separate distinct questions so one resolved point does not conceal another open dependency.
- Evidence basis Keep supporting and opposing sources, relevant passages, versions, observation dates, reliability and scope. Retain missing or unavailable evidence explicitly. A source pointer that no longer identifies the reviewed version weakens the decision record.
- Operational effect List affected pages, claims, routes, graph assertions, priorities, files and releases. Identify what can continue independently and what must remain provisional or held.
- Resolution rule Name the required evidence, accountable owner, review date, deadline or event and temporary handling. Define what counts as resolution. A deadline passing does not automatically make the assumption true or authorize the blocked action.
- Owner, scope and review state Keep the applicable market, version, effective period and uncertainty with the state. Record who can accept the resolution, the next action and the trigger that reopens the issue after a source or dependency change.
Resolve, propagate and preserve the earlier reasoning
Resolution replaces a temporary decision with a supported one, or confirms that the dependency must remain open. Preserve the previous assumption and why it was used. Earlier outputs may differ for a reason that future reviewers need to reconstruct.
- Check the exact resolution condition. Compare the new evidence with the recorded question, subject and scope. A new source that answers a different version or market does not close the original issue.
- Record the disposition and rationale. Mark the issue resolved, superseded, disproved or still open as appropriate. Retain both the former working interpretation and the evidence that changed or confirmed it.
- Replace the temporary handling. Update the accepted source or setting at its responsible owner. Do not silently turn a provisional label into a final state while leaving dependent files or technical assumptions unchanged.
- Recheck affected outputs. Use the recorded operational dependencies to reopen the claims, routes, graph assertions, packages or approvals that consumed the assumption. Repair the smallest affected unit and preserve unrelated accepted work.
- Carry the remaining boundary forward. Keep unresolved evidence, responsible owners, next review event and the valid next action with the handoff. An exception state explains a real dependency; it is not a shortcut around required evidence or acceptance.
Questions about assumptions and conflicts
Can work continue while a point is unresolved?
Yes, when the chosen work remains supported and independent of the unresolved premise, or when a bounded provisional output is appropriate. Keep consequential publication or technical setup choices held when their required input is missing.
How does a missing fact differ from a conflict?
A missing fact lacks the needed evidence. A conflict has competing assertions that appear incompatible after comparing subject, version, market and period. Record which condition applies so the next owner knows what evidence to seek.
Should the newer source always win?
No. Authority, claim fit, applicable version and effective period also need review. A recently edited page can describe a different scope or repeat an older assertion.
Should a resolved assumption be deleted?
No. Retain the former premise, temporary decision, resolution evidence and affected outputs as history. That record explains why earlier versions differed and which work was rechecked.
Does a resolved register guarantee SEO outcomes?
No. It makes uncertainty, evidence and decisions inspectable. It does not guarantee indexing, rankings, search features, traffic or conversions.
Related decisions and source reading
Project Manifest and Shared State
Index the affected artifacts, accepted states and unresolved dependencies.
Source Freshness and Expiry Control
Check if the apparent disagreement reflects an expired source or a different effective period.
Planning and production process
Carry a supported decision and its remaining limits into the next stage.
Process documentation library
Find related methods for evidence, review and acceptance.
Evidence Labels and Provenance
Keep source assertions, analysis and unresolved evidence in their correct classes.
Source Context for Topical Maps
Retain the subject, audience, version and claim scope while resolving ambiguity.
The register is an instructional process record with hypothetical cases. It does not resolve a real site setting, policy dispute or product identity. The temporary action remains limited by its evidence, scope and consequences; the record does not create facts or grant authority by assigning a label.