Design the lifecycle of phrase alignment decisions and reevaluation

[Maya-Kid]

I am withdrawing #801 in favor of a design discussion. The original failures are real, but my patch treated candidate filtering and retirement too locally. The review exposed interactions between signature identity, cached decisions, ontology changes, and job scheduling. I do not think continuing to add local fixes is a sound way to establish that lifecycle.

Observations and scope

On the tested dev baseline e894fa1:

• Phrase candidate filtering excludes subclasses from properties declared on their ancestors.
• When a property edit removes all candidates from an automatic binding, the worker skips the signature instead of retiring its unsupported typed projection.

The attempted implementation exposed additional problems; these should not be mistaken for regressions already present on dev:

• In Respect inherited phrase candidates and retire unsupported bindings #801 at 9edb707, recording structural none before kind-word classification leaves an old signature row behind after the endpoint class changes. stale keeps returning that row, but the worker has no live signature to reevaluate, so repeated runs keep queuing work. The reviewer reproduced three consecutive rounds with one stale row and one queued job; dev converged in that scenario because it did not write the old negative row.
• Once inherited bindings are supported, parent-edge edits need invalidation in both directions: adding an edge can reopen a negative, while removing one can invalidate a bound decision and its typed projection. Property timestamps alone do not cover this.
• Widening candidates in code is insufficient unless the model is also shown the inheritance basis.

A stale signature over the candidate limit can also keep requeuing without becoming executable. This remains unresolved in the withdrawn revision.

The final revision a4b98c0 excludes orphaned signatures from stale work and adds model context. Its Linux checks passed (932 tests; one existing network test ignored), but that is not evidence of a complete lifecycle design. Tests used real PostgreSQL and a scripted local model, not a live-provider quality evaluation. The code, regressions, and detailed review remain available in #801 as investigation evidence, not a recommended implementation.

Design questions

• What identifies the inputs a decision actually considered, including class hierarchy and property definitions, and how does that relate to An ontology edit during type alignment can be hidden by the response timestamp #795?
• When endpoint classes or live statements change, what happens to automatic and human decisions for the old signature? Which records are retained, invalidated, or removed?
• How are structural absence, model rejection/disagreement, candidate overflow, and retryable failure distinguished so that scheduling only retries work that can progress?
• How do decision changes reach the typed projection while preserving human precedence and other valid supporting sources?

A design should establish that unchanged inputs eventually leave no queued work, relevant changes make decisions reevaluable, and unsupported automatic projections retire without losing open statements or human choices. Regression coverage should include unknown-to-known endpoint transitions, parent-edge addition/removal, overflow and recovery, edits during model requests, and concurrent human decisions.

Related: #795 (in-flight input freshness), #798 (review/aligner locking), #800 (materialization in review requests), and #725 (decision review queues). This issue covers the phrase-decision lifecycle and its architectural boundary; it does not replace those narrower reports or prescribe a new revision schema or scheduling mechanism. An agreed design/ADR should precede a replacement implementation.