RFC 0004: Optional actor attribution for decisions and universe selections

[BenjaminNavet]

Tracking issue: #53

An astra.yaml records what was decided and why, and a universe records which
option was chosen. Neither records the who. This RFC adds a small optional actor
layer — a registry of the humans and agents on an analysis, plus fields naming who
proposed an option, who ruled one out (and when, and on what judgment), and who
selected or reviewed a pick in a universe. Every field is optional; nothing about how
decisions or selections are recorded changes.

It reuses CRediT and ORCID rather than inventing a vocabulary, and stays
capture-agnostic: any workflow that knows who proposed an option and who ruled on it
can fill the fields.

Settled in this draft

• One closed Role enum, not two. The human/agent split is a per-role allow-table
  enforced by astra-tools, because a slot's legal range cannot depend on another
  object's type. Two enums would express no constraint one does not — the agent list
  is a strict subset of the human list.
• conceptualization and supervision are human-only. A human frames the decision
  and signs off; every other role, including the three extensions (planner,
  executor, researcher), is open to both actor types.
• One attribution value, reused everywhere: either a bare actor id, or
  {actor, role}. No parallel *_role slots.
• Corrections need no new structure — a caught mistake is recorded with the
  existing excluded / excluded_reason, plus excluded_by / excluded_at /
  exclusion_rationale. No corrections: object, no revision log.
• excluded_reason and exclusion_rationale stay distinct: what was observed
  versus the judgment that made it dispositive. Collapsing them makes an exclusion
  unauditable — the worked example shows a case where the observation alone reads as
  the option outperforming its replacement.

Open — feedback wanted

• How does a tool learn who the human is? This is the question the whole layer
  lives or dies on. The agent half of the registry is automatic — a harness knows its
  own model, harness and version. The human half cannot be inferred, and reciting
  an ORCID mid-session is unnatural, so this is where the actor layer either gets
  adopted or gets skipped. The RFC sketches two non-exclusive mechanisms — a user-level
  config (astra config set actor.orcid …, copied into the record at authoring time,
  git's model rather than a pointer to a machine-local file), and validation-as-prompt
  (astra validate naming the missing field and stating the value must be asked of
  the user, never invented). Both are tooling, not schema, and astra-tools has no
  config surface today. Should this be settled here, in a companion tooling RFC, or
  as an astra-tools issue?

• Does reviewed_by presuppose an agent selected_by? Human review is most
  meaningful over an agent's pick, but a human reviewing another human's pick is also
  valid. Should the schema constrain the pairing, or is this a rubric matter?

• ResearcherId: named slots or a generic scheme/value list? Named slots (orcid,
  arxiv, openalex, wikidata, google_scholar) are self-documenting and let each
  id carry its own validation pattern, but a new scheme means a schema edit. An
  identifiers: [{scheme, value}] list is open-ended and linked-data-native, at the
  cost of weaker per-scheme validation. The draft currently proposes named slots.

Reference implementation

A prototype lives on main of the Fosowl forks: the closed Role enum in
astra-spec (src/astra/schema/actor.yaml), the ROLE_ALLOWED_TYPES allow-table and
semantic enforcement in astra-tools (src/astra/validation/semantic.py). Per the RFC
process, this PR carries the document alone; implementation PRs follow acceptance,
one per repo.

---

Draft while the design stabilizes. Will mark ready for review — and flip the
frontmatter to status: Active — once the questions above are settled.