Proposal: protocol-neutral semantic annotations for Runtime Events

## Proposed first step

Open a feature request / design discussion before changing the RuntimeEvent contract.

**Title:** Proposal: protocol-neutral semantic annotations for Runtime Events

### Problem

Maka already preserves a durable, append-only Runtime Event Log as the canonical record of model messages, tool calls, permission decisions, and termination facts. The event contract records what happened, but it does not yet provide a protocol-neutral way to describe the semantic status of a claim or event:

- whether content is an observation, inference, memory, decision, or review;
- whether its grounding is direct, derived, aggregated, or reported;
- how confidence and verification should be represented;
- optional provenance for an agent or source.

This makes it harder for projections and evaluation tooling to distinguish a tool-verified observation from a model inference, without parsing free-form text or adding product-specific fields.

### Desired outcome

Add an optional, backward-compatible semantic annotation namespace that can be attached to Runtime Events and preserved by the event log and its projections. The namespace should be:

- inert when absent;
- protocol-neutral and independent of any model provider;
- progressively disclosed (one or more fields may be present);
- lossless across storage, replay, and export;
- usable by Eval without making semantic annotations part of scoring by default;
- explicit that confidence and verification are metadata, not permission or security decisions.

LAR-1 is a candidate vocabulary and reference schema for this namespace. It is a semantic overlay, not a replacement for Maka's Runtime Host, MCP integration, or event model:

### Sketch

The exact placement should follow Maka's existing event-contract conventions. One possible shape is a namespaced optional field:

```ts
export interface RuntimeEventSemanticAnnotations {
lar1?: {
T?: 'now' | 'past' | 'recall' | 'future';
S?: 'here' | 'there' | 'meta';
C?: 'obs' | 'hyp' | 'mem' | 'det' | 'inf' | 'rev';
E?: 'direct' | 'derived' | 'aggregated' | 'reported';
L?: number; // 0..1
V?:
| 'unverified'
| 'verified_human'
| 'verified_tool'
| 'verified_crossref'
| 'verified_peer';
R?: number; // 0..1, optional reasoning-effort metadata
provenance_key?: string;
};
}
```

Whether this belongs on the event envelope, in a provider-neutral content metadata object, or in a separate event action is intentionally left open for review. The important invariant is that it must not be confused with `RuntimeInvocationRoute` provenance, permission state, or provider-owned metadata.

Example:

```json
{
"type": "tool-result",
"semantic": {
"lar1": {
"T": "now",
"S": "there",
"C": "obs",
"E": "direct",
"L": 0.99,
"V": "verified_tool"
}
}
}
```

### Scope of a possible follow-up implementation

1. Add closed-domain TypeScript types and pure validation helpers in `@maka/core`.
2. Add round-trip tests for absent, partial, valid, and invalid annotations.
3. Preserve annotations through the canonical event log and relevant projections.
4. Add a small export/inspection representation; no UI requirement in the first PR.
5. Add an opt-in Eval diagnostic or artifact rather than changing default scores.
6. Document ownership and trust semantics: annotations are claims or attestations carried by the event, not security boundaries.

### Non-goals

- No required LAR-1 dependency for Maka.
- No change to MCP or A2A wire protocols in the first contribution.
- No mandatory annotation generation by the model.
- No use of annotations as permission, sandbox, authentication, or authorization decisions.
- No cryptographic identity requirement for every event.
- No claim that a confidence number is independently calibrated.

### Alternatives

- Keep semantic information in free-form text: easy, but not machine-readable or reliably auditable.
- Add Maka-specific fields: simpler locally, but less interoperable and likely to duplicate an existing vocabulary.
- Encode the data only in Eval: useful for experiments, but loses event-level provenance and cannot serve runtime projections.
- Add an opaque `metadata` bag: flexible, but weakly specified and prone to provider-specific drift.

### Verification idea

A focused test fixture could replay a short sequence containing:

1. a user request;
2. a tool result annotated as `C=obs, E=direct, V=verified_tool`;
3. a model conclusion annotated as `C=inf, E=derived`;
4. an unannotated legacy event.

The expected result is that all four events remain valid, annotations survive round-trip serialization, and legacy behavior is unchanged.

### Attribution and provenance

The vocabulary and schema are from the LAR-1 project, licensed under MIT in the reference repository. Any implementation in Maka would be contributed under Apache License 2.0 according to Maka/ASF contribution requirements. This proposal is an interoperability discussion, not a request to vendor the LAR-1 repository.

---

AI assistance was used to inspect the repository and prepare this draft. The contributor of record reviewed and authorized this submission.