Consent Model
~alter uses a progressive engagement model with four levels. Each level reveals new capabilities while expanding the scope of data sharing. Consent is granular, revocable, and enforced at every layer of the stack, from REST API endpoints to MCP tool invocations.
Engagement levels
Individuals progress through four engagement levels. Each level requires explicit consent before they emerge, and some capabilities are hard-gated at the backend.
Explorer
Basic profile, anonymous Discovery- Create an account and complete Discovery
- View your archetype and trait summary
- Browse public contexts and opportunities
- No identity data shared with collectives
Learner
Identity verified, consent controls active- Identity verification completed
- Pair data-source connectors to deepen your identity vector. Live in phase one for GitHub, Obsidian, Discord, and Wallet. Others are coming soon.
- Set per-category consent for data sharing
- Eligible for the Naming Ceremony (Mirror + identity reveal)
Augmented
~Alter activation, credential sharing, x402 earning- Activate your personal ~Alter (hard gate)
- Share verifiable credentials with third parties
- Begin earning Identity Income via x402 transactions
Deployed
Full matching, collective interactions, placement- Full identity matching enabled (hard gate)
- Direct collective interactions
- Outcome tracking and confirmation
- Full Identity Income earning
Hard gates vs soft gates
~alter distinguishes between hard gates (backend-enforced, cannot be bypassed) and soft gates (frontend messaging that encourages progression).
Hard gates
- ~Alter activation requires L3
- Matching requires L4
- Identity Income earning requires L3+
- Credential queries require individual consent
Soft gates
- Deeper attunement (“emerges as Discovery deepens”)
- Richer trait detail (“available at L3”)
- Identity Income insights (“available once you reach L3 (Augmented)”)
- Share features (“complete your profile to share”)
Granular consent types
At L2 and above, individuals control exactly which categories of data can be shared and with whom. Consent is set per category and can be updated at any time.
| Category | Min. level |
|---|---|
trait_profile | L2 |
archetype | L2 |
competencies | L3 |
full_vector | L3 |
matching | L4 |
Consent in MCP context
AI agents interacting via the MCP Identity Server must respect consent boundaries. The server enforces these automatically. Agents cannot bypass consent even with valid authentication or payment.
// Agent requests trait data for an individual who hasn't consented
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32002,
"message": "The target member has not granted your caller tier permission for this query.",
"data": {
"error_code": "consent_denied",
"http_status": 403
}
}
}Per-tool capability consent
Connecting an agent over OAuth does not hand it the whole toolset. The agent receives a capability token scoped to exactly the tools you allow, one grant at a time. Consent is recorded per tool, so allowing one tool never allows another, and each grant can be revoked on its own.
- Each tool maps to the scopes it needs; the capability token carries only the scopes you have consented to.
- A call to a tool you never granted is refused, even with a valid token and payment.
- Read tools and write tools are consented separately; a write tool additionally needs a recorded consent event before it runs.
This layers on top of the data-category consent above: category consent decides whose data an agent may read, per-tool consent decides which operations it may perform.
Consent withdrawal
Individuals can revoke consent for any data category at any time. Withdrawal is immediate and affects all subsequent queries:
- •All pending and future queries for the revoked category return 403 Forbidden.
- •Previously completed and paid queries are not reversed. Transaction records are retained for audit.
- •Individuals can re-enable a category at any time. No cooldown period.
| Method | Path | Auth |
|---|---|---|
| PUT | /orgs/queries/consent/categoryUpdate category consent | jwt |
| GET | /orgs/queries/consent/configGet consent configuration | jwt |
Privacy by design
~alter’s consent model is built on three privacy principles:
Data minimisation
Endpoints return only the data categories the individual has consented to. Trait responses use bucketed tier labels (e.g. “high”, “moderate”), never raw numeric scores. PII is never stored in trait or matching databases.
Purpose limitation
Each consent grant is scoped to a specific data category. Organisation agents cannot repurpose trait data for categories they are not authorised to access. All queries are logged with purpose and querying entity.
Retention limits
Raw assessment responses are retained for 90 days only. Extracted trait signals persist as anonymised vectors. Full data deletion is available on request (APP 11.2 compliance).
Safety principles
~alter’s consent model is underpinned by the architectural safety constraints, which mandate behavioural integrity monitoring, wellbeing detection, and manipulation prevention across all agent interactions. These principles are enforced at the platform level. Individual agents cannot override them. For the broader ethical framework, see Ethics.