Parent: #94
Why this exists
Auths currently explains many strong technical capabilities at once: cryptographic identity, Iroh transport, delegated authority, approvals, lifecycle controls, and formal assurance. The combined story is defensible, but it makes the smallest useful adoption path hard to see.
This workstream owns the roughly 40% positioning problem: make it immediately clear what Auths does, who V1 is for, and how teams can adopt one layer without committing to the rest.
Work
Deliverables
- A concise messaging hierarchy: category, one-sentence promise, supporting outcomes, and proof points.
- A documented three-layer adoption model.
- Updated top-level README and launch copy.
- A clear V1 audience/workflow decision that can guide engineering prioritization.
- Notes from at least a small set of external positioning conversations.
Acceptance criteria
- A new user can explain Auths' value in one sentence after reading the introduction.
- The identity-only, delegation, and governance adoption paths are visibly distinct.
- A user interested only in signed identity exchange does not conclude that capabilities or approvals are mandatory.
- The V1 audience and first workflow are specific enough to accept or reject roadmap work.
- Technical claims are consistently connected to concrete user outcomes.
Parent: #94
Why this exists
Auths currently explains many strong technical capabilities at once: cryptographic identity, Iroh transport, delegated authority, approvals, lifecycle controls, and formal assurance. The combined story is defensible, but it makes the smallest useful adoption path hard to see.
This workstream owns the roughly 40% positioning problem: make it immediately clear what Auths does, who V1 is for, and how teams can adopt one layer without committing to the rest.
Work
Deliverables
Acceptance criteria