You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a3a9dd8
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: docs/lifecycle.md
+49-12Lines changed: 49 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,24 +33,55 @@ therefore survive the process that computed them: `plan` and `apply` are
33
33
separate CLI invocations and separate MCP calls, and neither shares memory with
34
34
the other. The 100 most recent plans are retained.
35
35
36
-
### Conservativity: the one part of a plan that is about meaning
36
+
### Conservativity: what the change means
37
37
38
38
Everything above is about SHAPE. A change that adds one `rdfs:domain` triple adds
39
39
no class, removes nothing, has a blast radius of zero and scores `low`, while
40
-
retyping every existing individual of that property. Pass
41
-
`check_conservativity: true` and the plan also reports whether the change alters
42
-
any consequence over the names the store already uses, with the rule and the
43
-
premises the base lacked behind every row.
44
-
45
-
It is opt-in because it reasons both graphs to a fixpoint, and when it is off the
46
-
`conservativity` block is still there and reads `ran: false` with the reason: a
47
-
missing block and a clean block look the same to a dashboard. It is never fatal;
48
-
a check that cannot run leaves `conservativity.skipped` set and the plan is still
49
-
returned. The verdict is a WORD rather than a boolean, and it is conservativity
50
-
with respect to a Horn rule table rather than in a description logic, which
40
+
retyping every existing individual of that property. The `conservativity` block
41
+
reports whether the change alters any consequence over the names the store
42
+
already uses, with the rule and the premises the base lacked behind every row.
43
+
44
+
It is on by default since #196 and costs a fixpoint over both graphs; skip it with
45
+
`--no-conservativity` (CLI and `batch`) or `check_conservativity: false`
46
+
(`onto_plan`). When it is off the `conservativity` block is still there and reads
47
+
`ran: false` with the reason: a missing block and a clean block look the same to a
48
+
dashboard. It is never fatal; a check that cannot run leaves
49
+
`conservativity.skipped` set and the plan is still returned. The verdict is a WORD
50
+
rather than a boolean, and it is conservativity with respect to a Horn rule table
51
+
rather than in a description logic, which
51
52
[docs/modules-and-conservativity.md](modules-and-conservativity.md) states in
52
53
full.
53
54
55
+
### Logic: what the change breaks
56
+
57
+
Conservativity does not see a change that breaks the ontology. Adding
58
+
`Manager rdfs:subClassOf Person` and `Manager owl:disjointWith Agent`, where
59
+
every `Person` is an `Agent`, leaves `Manager` with no possible instance; adding
60
+
`Machine owl:disjointWith Person` and `alice a Machine`, where `alice` is a
61
+
`Person`, makes the ABox inconsistent. Both remove nothing and both used to score
62
+
`low` (#336). The `logic` block answers this, relative to the store, so a defect
63
+
the store already had is never charged to the change:
64
+
65
+
| field | meaning |
66
+
|---|---|
67
+
|`new_defects`| findings of the eight `defects` kinds in the proposed graph that the store did not have; `null` if the check could not run |
68
+
|`new_defects_by_severity`, `new_defect_findings`| the same, by severity, and listed (at most 50) |
69
+
|`abox_consistent`| the owl-dl tableaux on the proposed graph: `false` on a clash it found, `true` only when the search finished and the graph uses no construct the tableaux does not model, otherwise `null`|
70
+
|`abox_consistent_before`| the same question of the store, asked only when the proposed graph is inconsistent; `null` otherwise |
71
+
|`checked_by`, `reason`| what ran, and in words why each answer is what it is; `not_checked` when skipped |
72
+
73
+
A new `error` or `warning` defect, or an inconsistency the store was not proven to
74
+
have, sets `risk_score` to `high`, and `risk_reasons` says which. An `info`
75
+
finding is listed and does not move the score. The consistency half runs under
76
+
the `[reasoner]` budget (`tableaux_test_timeout_ms` per phase, under
77
+
`classify_timeout_ms`), and a run that exhausts it reports `null` with the reason,
78
+
never `true`. Skip the whole block with `--no-logic-check` or
79
+
`check_logic: false`.
80
+
81
+
The exit code of `plan` does not change with the verdict: it is 1 on an error and
82
+
0 otherwise, as it always was for a `high` score from removals. A pipeline gates
0 commit comments