Research: FeaVer/Ultimate-style property-guided model extraction and source-level witnesses (bounded spike) #447

Classification

• Type: bounded research / source-backed architecture evaluation
• Priority: P3 / research backlog; not a production feature or model-checker integration request
• Area: Roslyn → OwnIR → domain-specific abstraction → protocol/property checking → source-level witnesses
• Primary prior art: Bell Labs FeaVer / Modex, Ultimate Automizer / Büchi Automizer / LTL Automizer (source)
• Secondary algorithmic prior art: Mata (used by Z3-Noodler)
• Related Own.NET: P1: Add Obligation Protocols for project-specific barrier-sensitive rules #272 (obligation protocols), P2: Extend MOS/effect summaries to protocol and barrier effects #274 (protocol/effect summaries), feat(progress): Own.Progress — detect consume-or-exit loop stalls (PRG001) #275 (loop progress), State protocols: affine tokens — an unspent (terminal) state token must not be OWN001 #392/State protocols: diagnostics on protocol tokens use IDisposable wording ("used after it is disposed") #393 (state tokens), Research: evaluate Tabby-style stateful path pruning for bounded ownership diagnostics #424 (stateful path pruning), Research: IKOS-inspired abstract-state soundness oracle and operator audit (bounded spike) #433 (abstract-state soundness oracle), Research: Tai-e-inspired semantic fact assertions and selective precision (bounded spike) #443 (intermediate fact assertions), Research: evaluate BAIT Büchi inclusion and antichain fixpoints for temporal ownership protocols (bounded spike) #446 (BAIT/Büchi language inclusion and antichains)

Why this is worth investigating

There are real precedents for deriving smaller verification models from production source instead of requiring users to hand-author entire formal models:

1. FeaVer / Modex: Bell Labs used an extraction map to mechanically derive verification models from the C call-processing implementation of Lucent PathStar and checked a property library with Spin; failures had concrete scenarios. The transferable idea is property-guided extraction with source provenance and actionable traces, not an out-of-the-box C# analyzer.
   • FeaVer project account
   • FeaVer components
   • Modex source
2. Ultimate: distinguishes safety via Automizer trace abstraction, termination via Büchi Automizer, and LTL properties via LTL Automizer. These are different verification questions; do not treat every ownership/obligation violation as a Büchi problem.
   • Ultimate tools
   • Ultimate implementation
   • LTL Automizer
3. Mata: efficient finite-automata operations, with concrete library reuse by Z3-Noodler; inspect its representation and inclusion/pruning machinery only if a measured Own.NET state-space bottleneck exists. Z3-Noodler's use of Mata is not proof that its exact antichain inclusion routine is on the hot path.
   • Mata
   • Z3-Noodler

Core question: Can one small property-guided model-extraction + witness technique improve an adjudicated real Own.NET protocol/progress finding over the current Roslyn→OwnIR→dataflow/MOS path, without introducing a second general-purpose verification stack?

Gate 0 — scope/dedup inventory (required before experiments)

• Pin the Own.NET baseline SHA, analyzer mode and Python/Rust parity expectations.
• Inspect actual P1: Add Obligation Protocols for project-specific barrier-sensitive rules #272/P2: Extend MOS/effect summaries to protocol and barrier effects #274/feat(progress): Own.Progress — detect consume-or-exit loop stalls (PRG001) #275 implementations and existing witness/SARIF codeFlows support; identify what is already implemented vs proposed in those issues.
• Inventory which Roslyn source facts / OwnIR control-flow, effects, calls, exceptional exits, loops, barriers and source spans survive lowering. Check Research: Tai-e-inspired semantic fact assertions and selective precision (bounded spike) #443/Research: IKOS-inspired abstract-state soundness oracle and operator audit (bounded spike) #433's oracle constraints.
• Pin upstream docs, tool revisions and concrete implementation paths for FeaVer/Modex/Ultimate. Distinguish demonstrated historical commercial deployment (FeaVer) from academic/open-source verification frameworks (Ultimate); do not infer present-day commercial deployments.
• State precisely what additional fact or representation the proposed experiment needs. Missing frontend facts are a representation gap, not evidence that a new solver is better.

Gate 1 — choose exactly one relevant real discrepancy (or NO-GO)

Prefer a reviewed existing C# test/real-code defect involving property-specific source abstraction and trace quality, for example:

• An obligation opened and not closed before a forbidden notification/call barrier (P1: Add Obligation Protocols for project-specific barrier-sensitive rules #272/P2: Extend MOS/effect summaries to protocol and barrier effects #274).
• A loop with a feasible continue/back-edge lacking the recognized progress measure (feat(progress): Own.Progress — detect consume-or-exit loop stalls (PRG001) #275).

Before proceeding, record one falsifiable expected improvement:

• Accuracy: find an adjudicated positive the baseline misses, without losing confirmed positives;
• Precision: eliminate an adjudicated false positive with valid feasibility evidence, not by silence under unknowns;
• Evidence: produce a shorter, source-explained witness for the same correct diagnostic (count strictly as evidence/UX improvement, not accuracy improvement).

Include a benign near-neighbor, a missing/opaque call, and an exception/loop boundary as applicable. A finite safety/loop-progress case is not automatically an ω-language or LTL verification task. Only test Büchi/LTL if #446 separately identifies a genuinely unbounded temporal property and its fairness assumptions.

If no distinct real discrepancy beyond #272/#274/#275, #433/#443 or #446 survives: NO-GO; close with a short source-backed design map.

Gate 2 — one isolated FeaVer/Ultimate-inspired micro-PoC (conditional)

If Gate 1 passes:

1. Reuse existing OwnIR and analyzer/test harness; define a property-directed projection of only relevant events/states, e.g. open-obligation, barrier, close-obligation, return/throw, or guard, progress, back-edge, exit.
2. Spell out the projection's semantics: omitted statements, control/exception edges, aliases, method summary assumptions, unresolved calls, path feasibility, and loss of precision. Never call the projected model a faithful complete representation without proving the selected property is preserved.
3. Run a minimal offline verifier/trace analysis over the projection, using a basic finite-state monitor/graph search before introducing any external model checker.
4. Return a deterministic source-linked witness with event order and source locations. If infeasibility/unknown/unsupported prevents proof, report UNKNOWN / INCOMPLETE, not SAFE; distinguish candidate trace from feasible execution.
5. Compare directly with the pinned baseline and existing evidence. Report correctly detected/retained/missed positives, adjudicated false positives, witness usability, runtime/memory, model size, and unsupported-case count.
6. Keep all artifacts in a disposable, test-only experiment; no production schema changes, mandatory user-authored Promela/LTL, JVM dependency, or separate permanent verification engine.

Optional Mata connection (not a parallel workstream)

Only with a measured frontier/state explosion in that specific pilot, compare a small sound subsumption/frontier optimization to existing dataflow worklist behavior. Require explicit domain ordering for resource identity, aliases and must/may/unknown; cite #446 and avoid starting a duplicate BAIT/antichain project.

Deliverables / acceptance criteria

• Source-backed comparative note: FeaVer model extraction/property mapping/witnesses vs Ultimate safety/termination/LTL tracks vs Mata automata operations; distinguish applicable and inapplicable parts.
• Own.NET stage/feature inventory with baseline SHA and pointers to relevant current implementations/issues.
• Exactly one independently adjudicated discrepancy and a declared target metric; or explicit NO-GO.
• If admitted: tiny deterministic event projection plus 1 true positive, 1 negative near-neighbor, 1 unknown/opaque case, and an adversarial control relevant to the selected construct.
• Baseline-vs-PoC results; measured runtime/memory as feasible; no suppression of confirmed findings, no false SAFE under incomplete analysis.
• Source-mapped, reproducible witness and clear classification of accuracy vs witness-only improvement.
• End decision: GO (bounded measurable benefit), NO-GO (no independent advantage), or DEFER (missing frontend fact/verified candidate).
• Any production implementation proposed later must be a separate issue with explicit owner approval and dual-engine parity plan.

Non-goals

• Porting Modex/Spin/Ultimate/Mata wholesale or replacing the existing Own.NET ownership/dataflow core.
• Claiming arbitrary C# safety, termination, or liveness proofs from an incomplete projection or bounded exploration.
• Reopening feat(progress): Own.Progress — detect consume-or-exit loop stalls (PRG001) #275's progress-diagnostic implementation in this research issue.
• Duplicating Research: evaluate BAIT Büchi inclusion and antichain fixpoints for temporal ownership protocols (bounded spike) #446's Büchi inclusion or generic antichain evaluation.
• Treating one historical industrial case study or solver competition results as demonstrated utility on current Own.NET workloads.