Raised by a user describing a mud-logging workflow: a well counts as gas-bearing when its total-hydrocarbon reading is above a threshold and the interpretation category is "gas anomaly" or "post-effect gas anomaly". Both values sit in a paragraph of the mud-logging report (an Excel sheet) or in the DDMS.

What works today

• The two inputs can be captured. Define Well with two attributes (total_hydrocarbon, number, %; interpretation_category, text) and extraction turns "全烃 12.3%，解释为气测异常" into dated attribute facts with the source passage attached (attribute facts: relation_types.kind = 'attribute', values in facts.object_value).
• If the DDMS is Postgres it can be mounted and the question asked in chat; the agent writes the SQL. Other engines are on the roadmap.
• For a handful of wells, asking the question in chat works: the agent reads the attribute facts and compares. It does not scale past tool-output limits and it is not a stored result.

What is missing

The rule itself has nowhere to live. The reasoning engine compiles ontology axioms only (transitive, symmetric, inverse, sub-property; 0002 rules out a user-defined DSL), and derivation runs over entity–entity facts: literal-valued attributes do not take part (derived_facts.object_id is NOT NULL). So "value > threshold" cannot be expressed, and "this well is gas-bearing" cannot be a derived fact with premises.

Shape of the feature

A rule layer over attribute facts, declared by people, evaluated like derivations:

• Declaration: a rule names a class or predicate to conclude, and a conjunction of conditions over one entity's attribute facts: numeric comparisons (>, >=, <, <=, ranges), category membership (in {…}), presence. Authored in the ontology workbench or as a file; never proposed by the model (same line as axioms: the reasoning engine's criteria are written by a person).
• Conclusion: a derived typing (Well → GasBearingWell) or a derived attribute fact (gas_potential = good), stored with the rule and premise facts like any other derivation, drawn as derived on the graph, never overriding an asserted fact.
• Time: validity is the intersection of the premise intervals, so a well that was gas-bearing on the 2023 reading and not on the 2025 one gets two intervals, not a flip.
• Maintenance: change the threshold, rerun; premises retracted, conclusion invalidated; same cadence and switches as materialised inference.
• Explanation: the entity panel shows the rule and the two facts, each pointing back to its passage.

Not in scope

Arithmetic across entities, aggregation, or anything that needs a general rule language. This is one entity, its own attributes, one conclusion.

Acceptance

Given the sample report, define the two attributes and the rule, upload, and the well appears as GasBearingWell with the rule and both facts as its explanation; lower the threshold below the reading and it disappears on the next run; the interval matches the report's date.

Roadmap entry: "Business rules".