Object Invocation Protocol · protocol specification
Designer Legibility Policy — A8 Feature vs Operator Exposure
§SELF — oip-designer-legibility-policy
What this page is: the boundary A8 made necessary — what about the designer is deliberately legible vs incidentally leaked. What it explains: the philosophy mandates maker-through-artifact audit; it does not mandate doxxing the operator. Why read it: success of A8 is a personal risk if the line is default, not decision.
Deliberately legible (feature — A8)
- Judgment and commitments encoded in system behavior (defaults, gates, refused actions).
- Ought externalized as rules, risk ceilings, objection intake, kill switches.
- Operating profile as orientation for authorized collaborators (
?profile=1class surfaces) — judgment, not street address. - Ledger of decisions (what the system did and denied) as audit of the maker's bled priorities.
Not intended as public legibility (incident / minimize)
- Legal name in error strings, UI chrome, or public group selftest prompts ("Ask <owner name>") — hygiene: use role ("owner") unless the owner opts in.
- Machine identity, local paths, schedule, precise location in public receipts or error text.
- Private chat content and credentials.
Decision rule
| Question | Default |
|---|---|
| Does revealing X help audit the ought? | May be legible |
| Does revealing X mainly identify the person/device without aiding audit? | Not public by default |
| Error strings | Role-based ("owner"), not personal name |
Operator action
Owner may tighten further (strip profile fields, imessage gates). Philosophy says: legible judgment is the feature; incidental identity is a bug unless explicitly opted in.