[PORT-002][RFC][P0] Define TableEvent v1 and prove table-kit → dmcheck compatibility with a golden session #8

Decision requested

Define the minimum table.event/1.0 envelope needed to make table-kit’s documented dmcheck compatibility real, then prove it with an installed-artifact golden session.

Priority: P0 — blocks dependable cross-tool use.

Evidence confidence: 99%. The exact schema remains an RFC decision.

Problem / evidence

The promised direct ledger handoff is not currently compatible. table-kit writes operational rows using fields such as actor and text; dmcheck expects transcript rows using author and content plus a separate engine-ledger shape. Event identity, source sequence, correlation, visibility, version, and provenance are inconsistent or absent. A direct handoff can silently produce zero compatible messages and a false-clean result.

CharacterCheck and srdcheck do not currently claim to consume a live session ledger. Their outputs should be joinable by stable references without expanding their product boundaries.

Proposed v1 scope

Publish a discriminated table.event/1.0 envelope with:

• immutable event, campaign, and session IDs;
• source kind/instance/native ID/sequence and an honestly defined attestation state;
• occurred and recorded timestamps;
• stable principal, actor, controller, and role;
• event type and typed payload;
• correlation and causation IDs;
• audience, visibility, and sensitivity;
• provenance: observed | derived | inferred | reported | decided;
• optional integrity predecessor/hash whose trust meaning is defined by the authority RFC.

The minimum v1 families are session, observed message/delivery/gap, turn/action, roll, narration/obligation, and evaluation. The RFC must explicitly classify consent, feedback, correction, ruling, and state families as v1 or reserved roadmap namespaces rather than silently converting the current “example, not a framework” into a full runtime specification.

Acceptance criteria

• An ADR assigns responsibility boundaries between table-kit, dmcheck, adapters, and any future host.
• Versioned JSON Schema, examples, and generated types ship independently of a source checkout.
• Explicit adapters convert current table-kit rows and Discord records into dmcheck transcript and engine semantics.
• Zero-compatible input refuses loudly; no mapping may silently drop all evidence and return clean.
• One golden session contains a clean path, a conduct finding, a legal Reaction, a transport gap, an obligation/narration case, and explicit session closure.
• table-kit and dmcheck consume their relevant events and preserve joinable evidence references.
• A proposed host/adapter can join CharacterCheck and srdcheck results by stable session/entity/correlation references without requiring those packages to consume TableEvent directly.
• Unknown future event types yield unsupported or structured skip, never a crash or false clean.
• Document a future N/N-1 compatibility policy plus a migration adapter from the current unversioned ledger.
• Platform-native IDs and sequence are treated as provenance; they are not described as cryptographic authentication by themselves.

Required tests

• End-to-end golden session using installed table-kit and dmcheck artifacts.
• Duplicate, out-of-order, missing-sequence, forward-schema, corrupted-event, and zero-compatible cases.
• Exact event identity and correlation preservation through adapters.
• Explicit proof that current field mappings cannot silently discard all evidence.

Dependencies

Can proceed in parallel with EvaluationResult. The authority/threat model must run alongside this RFC and gate the final attestation, visibility, and integrity semantics.

Suggested labels: P0, RFC, cross-repo, architecture, schema, interoperability, diligence, blocks-live-use.

Scope note: This is a cross-repository architecture proposal hosted temporarily in table-kit because this repository currently owns the session ledger and documents sibling-tool compatibility. It does not assert that table-kit already provides a suite host/control plane, or that dmcheck, charactercheck, and srdcheck currently consume a common event protocol. Repo-local containment work should proceed independently.