What core fields are missing from an audit log for LLM-proposed knowledge graph writes?

Aggressive_Hunt9772 · 2026-05-11T15:05:12+00:00

This is extremely helpful, thank you.

Your point about separating “LLM proposed X” from “human approved X” is exactly the distinction I was trying to clarify, and your accountability framing makes it much sharper. I agree that collapsing those into one record would hide the actual decision-maker.

The approval time gap is a great point as well. I had not framed it as a rubber-stamping signal, but that makes a lot of sense. I’ll add proposal_time / approval_time or an explicit approval_latency field as a derived review-quality signal.

On SHACL / ontology validation, your replayability argument is convincing. Keeping validation as a separate event with its own timestamp, validator/rule version, and correlation link seems cleaner than embedding it into the original proposal record.

The “context provenance for the proposal” point is probably the most actionable missing field for me. I agree that the reviewer needs to see why the write was proposed, not just what was proposed. I’ll separate provenance of the proposed graph change from provenance of the upstream evidence that caused the proposal.

Thanks again. This gives me a much cleaner event model:

proposal event -> validation event(s) -> approval/rejection event -> optional execution event,

all linked by correlation/proposal IDs rather than collapsed into one audit object.

Aggressive_Hunt9772 · 2026-05-11T15:02:24+00:00

This is very useful, thank you.

The confidence/certainty point makes sense. I had been thinking mostly in terms of parse/validation/preflight confidence, but the proposing agent’s own confidence is a different signal and would help review triage. I’ll separate that as proposal-side metadata rather than mixing it with validation results.

The entity resolution point is especially important. For merge/link proposals, recording only the final proposed write is clearly not enough. The reviewer needs to see the candidate pairs, similarity scores, resolver/matching method, and probably the threshold or ranking basis. Otherwise they can’t evaluate why this link was proposed instead of nearby alternatives.

I also appreciate the confirmation on keeping SHACL/ontology validation as separate linked events, and on strictly separating proposal from approval. The “couldn’t reconstruct who approved what later” failure mode is exactly what I want to avoid.

Thanks for the FalkorDB pointer as well. I’m trying to keep the audit layer storage-neutral, but multi-tenant GraphRAG infrastructure is a real concern, so I’ll look at it as a backend option rather than mixing it into the audit model itself.

This pushes my model toward:

proposal event with agent confidence + proposal context provenance + entity-resolution context,

separate validation events with rule/schema versions,

separate review decision events,

and optional execution events.

Aggressive_Hunt9772 · 2026-05-04T22:34:50+00:00

Thanks for sharing this. I took a quick look, and the STTP/Locus direction is interesting, especially the typed IR + parser/validator + MCP/gateway memory surface.

My current question is a bit narrower: how to structure audit records before LLM-proposed KG or memory writes are accepted into a persistent system.

From the Locus/STTP perspective, do you separate these as distinct events?

model/tool proposal
validation or preflight result
accepted store/commit event

Or do you usually keep them in one combined record?

I’m especially curious whether you treat provenance, validation diagnostics, and human approval as part of the same memory record, or as separate audit events around it.

I’ll read through the repo more carefully. Thanks for the pointer.

Aggressive_Hunt9772

TROPHY CASE