quantipixels Amọ̀ṣẹ́
Actively sharpen the project's domain model as concepts emerge and change.
Clarify the model
Read only evidence capable of settling the material meaning: the current domain-language source, governing decisions/policies, relevant code/tests/configuration/runtime behavior, and bounded history/provenance when it can resolve a conflict. Treat implementation and operations as evidence of current behavior, not automatic authority for domain intent.
When an ambiguous, overloaded, synonymous, or conflicting term can change scope, ownership, identity, state, policy, or behavior, do not silently choose a meaning. State the conflict, test it with the smallest concrete scenario that distinguishes the concepts, compare it with current domain language and relevant evidence, and propose canonical wording only when evidence or user/domain authority supports it.
When the user deliberately establishes or changes clear domain meaning, test only the boundaries needed to make that change internally coherent; do not manufacture ambiguity merely to justify an interview.
Challenge the model as concepts crystallize. A useful clarification may establish or separate:
- canonical terms and avoided synonyms;
- conceptual distinctions and identities;
- domain/context boundaries;
- semantic relationships or invariants; and
- contradictions between stated meaning and current behavior.
Return the resolved terms, relationships, invariants, distinguishing examples, and any conflicts or open decisions with their evidence.
Reconcile canonical language
Use the project's existing domain-language source or user-selected equivalent; do not create a competing source of truth. In repository work, read context when canonical language needs maintenance.
When a term or context relationship is confirmed and write authority exists, reconcile the applicable language source immediately rather than batching accepted vocabulary for a retrospective. Re-read the final text and verify it does not absorb implementation details, temporary scenarios, task history, specifications, or architecture rationale.
Exceptional durable knowledge
Domain clarification does not imply durable promotion. Ordinary implementation rationale, one-off discoveries, temporary decisions, and useful history stay in their normal plan/spec/PR/history surfaces.
Admit new durable knowledge only when current evidence supports it, it is stable beyond the initiative, and future work needs it to avoid a consequential wrong action rather than mere rediscovery. Updating an existing stale authority is separate from admitting a new record; apply that source's maintenance or supersession rules.
Use the project's existing destination or user-selected equivalent. For repository work, load only the applicable record contract:
- learnings — stable, non-obvious recurring project knowledge whose loss risks consequential wrong action;
- nongoals — durable project-wide exclusions; and
- ADRs — qualifying hard-to-reverse, surprising software/system decisions that resulted from a genuine trade-off.
Prefer stronger maintained sources such as domain context, architecture, policy, configuration, code, tests, runbooks, or product/service documentation when they already own the truth. Do not create a second durable record merely because information is useful.
When required reconciliation lacks a destination, evidence, or write authority, report the gap. For a selected .qp destination, use akosile.
Return
Return the resolved model delta and material conflicts/open decisions directly. When durable reconciliation was explicitly required, also report affected destination(s), verification/limitations, and RECONCILED | BLOCKED.