Follow aos-eval's entity and attribute abstraction #1125

New issue

Closed

opened 2026-08-23 00:35:36 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-23 00:35:36 +00:00

Member

aos-eval stopped hardcoding one deployment's vocabulary in the layer that is supposed to be agnostic. Landed in agentic-os#1195, cut as aos-eval-v0.6.0.

A challenge now tests one entity for one attribute. Challenge.role is entity, and boundary, against, and trait collapse into attribute. The declaration schema is aos-eval.attributes.v1 with an attributes: key and an entity: field. Profile.group_order is entity_order and boundary_order is attribute_order. The boundaries command group is attributes.

For this repository the entity is a deployed lane and the attribute is a clause, which is exactly the case the abstraction exists to serve: neither of those is a role or a boundary, and previously the shared taxonomy was still branching on role-fit and personality that this deployment never declares.

What moves here

eval/boundaries.yaml to eval/attributes.yaml, schema sirens-discord-ops.attributes.v1, boundaries: to attributes:, role: to entity:.
eval/aos-eval-profile.yaml: group_order to entity_order, boundary_order to attribute_order, and the boundary test type requires attribute rather than boundary.
scripts/boundaries.sh to scripts/attributes.sh, and the just boundaries and just boundaries-check verbs follow.
agents/dowel/evaluations/board-challenges.yaml records carry entity: and attribute:.
docs/sirens-echo-boundaries.md to docs/sirens-echo-attributes.md, plus the nine Go files that point at it in comments.

Not moving

EvaluationCase and RateCase keep cases:. Neither is graded by a human and neither has a pair, so neither is a challenge, and the probe layer's line stays where it is.

`aos-eval` stopped hardcoding one deployment's vocabulary in the layer that is supposed to be agnostic. Landed in [agentic-os#1195](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/issues/1195), cut as `aos-eval-v0.6.0`. A challenge now tests one **entity** for one **attribute**. `Challenge.role` is `entity`, and `boundary`, `against`, and `trait` collapse into `attribute`. The declaration schema is `aos-eval.attributes.v1` with an `attributes:` key and an `entity:` field. `Profile.group_order` is `entity_order` and `boundary_order` is `attribute_order`. The `boundaries` command group is `attributes`. For this repository the entity is a deployed lane and the attribute is a clause, which is exactly the case the abstraction exists to serve: neither of those is a role or a boundary, and previously the shared taxonomy was still branching on `role-fit` and `personality` that this deployment never declares. ## What moves here * `eval/boundaries.yaml` to `eval/attributes.yaml`, schema `sirens-discord-ops.attributes.v1`, `boundaries:` to `attributes:`, `role:` to `entity:`. * `eval/aos-eval-profile.yaml`: `group_order` to `entity_order`, `boundary_order` to `attribute_order`, and the boundary test type requires `attribute` rather than `boundary`. * `scripts/boundaries.sh` to `scripts/attributes.sh`, and the `just boundaries` and `just boundaries-check` verbs follow. * `agents/dowel/evaluations/board-challenges.yaml` records carry `entity:` and `attribute:`. * `docs/sirens-echo-boundaries.md` to `docs/sirens-echo-attributes.md`, plus the nine Go files that point at it in comments. ## Not moving `EvaluationCase` and `RateCase` keep `cases:`. Neither is graded by a human and neither has a pair, so neither is a challenge, and the probe layer's line stays where it is.

coilyco-ops referenced this issue from a commit

2026-08-23 00:36:02 +00:00

refactor(eval)!: adopt entity and attribute from the shared layer

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-23 00:36:02 +00:00

refactor(eval)!: adopt entity and attribute from the shared layer #1127

coilyco-ops closed this issue

2026-08-23 00:38:07 +00:00