# Derivation Logging and DirectProof Reconstruction

## Status

Superseded by [DR-007 Proof Model and Derivation Semantics Refinement](DR-007%20Proof%20Model%20and%20Derivation%20Semantics%20Refinement.md)

## Context

This repository's initial portfolio-oriented goal is to demonstrate agent-supported inference with inspectable, structured proof artifacts suitable for evaluation.
The baseline proof notebook and proof evaluation harness are centered on a `DirectProof` object that can be generated by a Research Agent, reconstructed from reasoner output, and assessed by Development Agent tooling.

The reasoning engine, however, operates over RDF triples and rule applications rather than over user-facing proof trees.
OWL 2 RL/RDF rules are presented in the specification as a partial axiomatization of the OWL 2 RDF-Based Semantics, and correspondence to Direct Semantics depends on additional conditions.
Therefore, engine-native trace data cannot assume that every fired rule corresponds one-to-one with a single named OWL 2 structural axiom.

At the same time, the `rdflib-reasoning-axioms` package already provides graph-scoped, schema-friendly Pydantic models such as `GraphBacked` and `StructuralElement`.
Those models are well suited for representing claims, supports, or ontology elements inside proofs, but they are not themselves a proof calculus.

The architecture therefore needs a stable separation between:

- engine-native derivation logging;
- user-facing proof reconstruction;
- graph/axiom payload models used inside proofs.

## Decision

- `rdflib-reasoning-engine` MUST treat derivation logging and proof reconstruction as distinct concerns.
- The engine MUST log fired rule applications in an engine-native structured form. That form MUST be centered on triple-oriented reasoning state such as derived conclusions, supporting premises, rule identifiers, variable bindings, and context.
- The engine's derivation log format MUST support arbitrary custom rules. It MUST NOT require every derivation step to map to a named OWL 2 structural axiom or Direct Semantics constructor.
- The engine MAY attach optional semantic metadata to a derivation step, such as OWL 2 RL rule identifiers, references to RDF-Based Semantics conditions, or known structural interpretations, when such metadata is available.
- `DirectProof` MUST be a structured proof representation reconstructed from derivation logs and/or proposed by a Research Agent. It MUST NOT be treated as the engine's primitive internal execution format.
- The initial proof calculus for `DirectProof` SHOULD be based on a single inference-step connective such as `RuleApplication`, representing conjunctive premises, rule metadata, and one or more conclusions for a direct proof step.
- Proof payloads inside `DirectProof` SHOULD reuse `GraphBacked` and `StructuralElement` instances where those models provide a natural typed representation of a claim or support.
- `DirectProof` MUST also support triple-level claims directly, because not every derived conclusion is most naturally represented as a structural element.
- Proof calculus objects and derivation-record objects MAY live in `rdflib-reasoning-engine`, with `rdflib-reasoning-axioms` as a dependency, so long as the proof calculus remains distinct from the axioms package's ontology-model scope.
- `rdflib-reasoning-middleware` remains the intended home for proof generation and proof evaluation interfaces exposed across the runtime boundary. Middleware MAY consume engine-native derivation logs and reconstruct `DirectProof` values for Research Agent-facing tools or Development Agent evaluation harnesses.

## Consequences

- The engine can remain faithful to triple-based rule execution while still supporting user-facing proof artifacts.
- `DirectProof` becomes a stable evaluation and interchange format without forcing the engine to execute directly over proof trees.
- The design supports partial semantic interpretation: a derivation step can carry a rule id alone, or a richer mapping to OWL/RDFS semantics when known.
- `GraphBacked` and `StructuralElement` become reusable proof payload types rather than being overloaded into proof operators.
- Arbitrary custom rules remain explainable because the derivation model does not depend on OWL-only terminology.
- Future implementation can add richer proof operators or semantic adapters without changing the core separation between engine-native traces and reconstructed proofs.

## Superseded By

- [DR-007 Proof Model and Derivation Semantics Refinement](DR-007%20Proof%20Model%20and%20Derivation%20Semantics%20Refinement.md)
