Review Actor schema against its broad parent semantics

[hwesterb]

Problem

Actor is described as a general capability-bearing execution entity whose listed contexts include Actor Model processes, microservices, serverless functions, physical actuators, and organizational roles. Its current data_schema, however, requires agent_id, public_key, and a fixed availability status enum.

That representation appears narrower than the mechanism and commentary. Adding more invariants would not solve the mismatch; the schema itself is part of the hashed definition and needs a deliberate migration decision.

Questions

• Which fields are truly identity-defining across every legitimate Actor context?
• Should the parent schema be representation-neutral, with cryptographic/networked fields moved to a descendant such as CryptographicActor or NetworkActor?
• Do any current dependents rely on the required public key or status shape?
• How large is the hash cascade, and what supersedes lineage is required?

Acceptance criteria

• Enumerate broad-use contexts and test each required field against them.
• Choose either a generalized parent schema or an honest narrower handle/family split.
• Keep authorization, persistence, and cryptographic policy in descendants or callers unless universal.
• Apply through the documented staging/sidecar/manual workflow with dependency-impact analysis and deterministic rebuild verification.

Related: #63 covers the separate over-specificity of Agent.