`row_kind="aggregate"` exists in the contract but still has no real semantic boundary

[Bol-C14]

Background

IterationRecord currently has three row_kind values:

• candidate
• event
• aggregate

The first two already have stable writer/reader/consumer semantics. aggregate, however, is still closer to a reserved contract label than a truly implemented object category.

Problem

aggregate currently has several boundary gaps:

1. It has no stable first-class meaning.

   • We have not clearly defined what object it represents, who owns it, what it is allowed to carry, or how it relates to candidate truth.

2. Existing aggregate / analysis information is still scattered across other surfaces.

   • For example, robustness-related information still mostly lives across candidate rows, CandidateSummary.robust_assessment, reporting, and suite aggregation surfaces.
   • In other words, the system is already starting to need “aggregate objects”, but there is still no unified typed boundary to hold them.

3. There is no stable producer/consumer chain for aggregate.

   • There are effectively no real writer / reader / reporting / replay / audit surfaces that rely on it today.
   • So while it exists in the contract, it is not yet a dependable semantic layer in the actual system.

Why this matters

This is not a bug on the current main path, but it is a strong signal of the next architecture theme.

As the following areas keep growing:

• robustness
• BO diagnostics
• suite compare
• batch analysis
• replay / audit / live tail

the system will increasingly need “analysis / aggregate truth” in addition to “candidate truth”.

If aggregate remains only a reserved concept, those semantics will continue to leak into candidate surfaces, summary fields, reporting logic, and suite-level derived outputs. Over time that is likely to cause:

• unclear ownership boundaries
• reader / writer semantic drift
• unstable audit and replay objects
• repeated assembly logic in reporting / compare / diagnostics
• future pressure to mix analysis truth back into candidate truth

Current conclusion

The repo has mostly completed the main Candidate family closure.

The next natural closure theme is likely:

from Candidate family toward Aggregate / Analysis family.

This issue is not asking for immediate implementation. Its purpose is to explicitly record that:

• aggregate is not truly implemented yet
• it is already one of the most natural next closure topics in the system
• we will likely need an independent, stable, auditable semantic boundary for aggregate / analysis objects