1---
 2layout: page
 3title: Base Log Type
 4---
 5
 6- **ADR:** 0016
 7- **Proposal Author(s):** @eddie-knight, @jpower432
 8- **Status:** Accepted
 9
10## Context
11
12[ADR-0012](./0012-schema-types) established "Log" as the term for artifacts containing multiple measurements and identified several future log types: Evaluation Log, Enforcement Log, Monitoring Log, and Audit Log.
13As new log types are added, each would redeclare those same fields independently — duplicating structure and risking divergence.
14
15## Decision
16
17Introduce a `#Log` base definition in `log.cue` containing the fields common to all log artifacts:
18
19| **Field** | **Type** | **Purpose** |
20|:---|:---|:---|
21| `metadata` | `#Metadata` | Standard artifact metadata |
22| `target` | `#Resource` | Resource being evaluated |
23
24Concrete log types embed `#Log` and add their specific entries. `#EvaluationLog` is refactored to use the base types:
25
26```cue
27#EvaluationLog: {
28    #Log
29    evaluations: [#ControlEvaluation, ...#ControlEvaluation]
30}
31```
32
33Future types (e.g., `#EnforcementLog`, `#AuditLog`) follow the same pattern.
34
35## Consequences
36
37- `#EvaluationLog` no longer declares `metadata` and `target` directly; changes to shared log fields propagate from one definition
38- New log types require only embedding `#Log` plus their own entries
39- No breaking change to the serialized YAML/JSON shape — embedded fields are structurally identical to inline fields in CUE
40
41## Alternatives Considered
42
43### Keep fields inline on each log type
44
45Each log type declares its own `metadata` and `target`. Simpler today with one type, but violates single-source-of-truth as the log family grows per ADR-0012.