Check reference

Find code without requirement ownership

An orphan-code finding asks which requirement owns a function's behavior. Resolve that question before adding an annotation: a nearby requirement ID is not necessarily the right owner.

What the check observes

In source-native mode, Proof examines supported source functions for recognized implementation ownership. Function annotations, legitimate file-level implementation declarations, and authored implementation targets can establish it. Internal helpers may inherit valid package documentation scope; public functions do not inherit that package scope. In overlay-audit mode, this source-annotation gate returns a policy pass without performing the orphan scan. Review the separate overlay trace and freshness checks; this pass does not establish that every imported function has a valid owner.

Check which scope owns the function

Source shape	Ownership interpretation	Review action
Recognized function-level Implements declaration.	Owns the annotated function.	Check that its requirement actually governs the behavior.
Recognized implementation declaration in the file header.	Can own multiple functions in that file.	Split ownership when the file contains unrelated responsibilities.
Valid package documentation scope.	May cover internal helpers, not public functions or tests.	Give public behavior an appropriate explicit owner.
Requirement ID mentioned only in prose.	Does not establish an implementation declaration.	Use recognized trace syntax after confirming the correct requirement.

For broad source-native coverage, keep project.checks.orphan_scope at its default, all. The alternative traced examines only files participating in recognized trace relationships and discloses skipped untraced files. It can warn about an unassessed breadth even with zero orphans in the selected set.

Example: one header claims too much

Illustrative case. A file contains cache eviction and access-control functions. A file-level Implements annotation for the cache requirement makes a broad ownership claim. If access control belongs elsewhere, annotate the functions at the appropriate granularity.

// Implements: SYS-REQ-042
func EvictExpired() { /* cache behavior */ }

// Implements: SYS-REQ-073
func CheckAccess() { /* authorization behavior */ }

Resolve the finding

Inspect the reported function and identify its observable responsibility, including failure behavior.
Link it to the requirement that actually governs it. Recover a candidate requirement if needed, then review its authority instead of treating existing code as the intended specification.
Use exclusions only for genuinely out-of-scope code. Keep their scope explicit and review them when the project boundary changes.

Run and interpret

proof lint --check orphan_code_clean

The default orphan scope is all recognized source files. A traced-only scope can omit wholly untraced files and reports a breadth warning when that narrows a source-native project. Recognized extensionless scripts are included.

An ownership link does not establish implementation correctness. A clean result is bounded by supported languages, configured paths, exclusions, and trace policy. It also cannot prove the requirement set is complete: a function can point to a requirement that is too broad or wrong.

Continue from here

Validate the annotation form. Review missing intent.

Bring one unowned function and the product promise it may serve. Bring a change to Proof.