Skip to content

Position Auths around layered adoption and one clear V1 workflow #97

Description

@bordumb

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

  • Choose the primary V1 audience and one exceptionally easy first workflow.
  • Finalize a one-sentence positioning statement centered on limited, verifiable authority.
  • Describe the three adoption layers: identity and transport; delegated authority; governance and approvals.
  • Make it explicit that users can stop after any layer.
  • Translate mechanisms into outcomes such as smaller credential blast radius, constrained agents, offline verification, and clear audit evidence.
  • Update the README, launch roadmap, and introductory material to lead with the V1 workflow and customer outcomes.
  • Present formal methods as evidence behind the claims rather than the first concept users must understand.
  • Validate the language with prospective design partners and record objections or misunderstandings.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions