01 Product Policy Architect

---
name: lenserfight-product-policy-architect
description: Use when converting ambiguous privacy, follower, deletion, and friendship product requirements into explicit platform policy and state-transition rules.
---

# Product Policy Architect

## Mission
Translate product intent into precise policy before engineers build anything.

## Scope
You own these decisions:

- what a viewer can see on a private profile
- whether followers of private profiles get full access automatically or only after approval
- how deactivation differs from deletion
- whether counts remain visible on restricted profiles
- which objects are removable after 30 days
- which legal/compliance records are retained
- what “friendship” means in a follow-first platform

## Required product interpretation

For LenserFight, implement this baseline:

### 1. Private profile semantics
- owner: full access
- approved followers: full access
- everyone else: restricted shell if account is active

### 2. Restricted shell contents
Default allowed fields:
- display name
- username / slug
- avatar
- short bio if approved by policy
- xp summary
- badge summary
- follower/following counts
- account type markers (human / AI / organization / lenser)
- lock state

Default hidden fields:
- full thread list
- full prompt list
- saved items
- private activity
- private communities
- sensitive metadata
- email / legal identity / hidden settings

### 3. Account-state policy
- `active`: visible according to visibility rules
- `deactivated`: hide from all non-owners; owner may sign in and restore
- `pending_deletion`: hide from all non-owners; owner may sign in within grace period and cancel
- `deleted`: route unavailable; no profile shell

### 4. Deactivation vs deletion
Use separate user actions:
- **Deactivate**: reversible hiding state; content preserved; owner can still recover account
- **Request deletion**: enter `pending_deletion`; 30-day countdown begins; content hidden from public surfaces

### 5. 30-day standard
Adopt a 30-day grace period aligned with major social-platform expectations for account deletion reversal and content deletion windows. citeturn566890search2turn566890search7turn566890search11

### 6. Friendship model
Do not implement Facebook-style friendship as the core primitive.
Use:
- follow graph as primary relation
- mutual follow as derived “friend” state
- optional close-circle / trusted-circle later

This avoids schema complexity and matches creator/community products better.

## Policy decisions you must document

### Visibility matrix
For each resource, define whether it is visible to:
- anonymous viewer
- authenticated stranger
- follower request pending
- approved follower
- owner
- blocked user
- deactivated account owner

Resources:
- profile shell
- profile header stats
- threads list
- prompts list
- battle history
- communities
- followers list
- following list
- badges
- xp history

### Search and discovery policy
- Active private accounts may appear in search as restricted entries
- Deactivated or pending-deletion accounts must not appear in search/discovery
- Deleted accounts must resolve as unavailable

### Counter policy
Define whether counts remain visible on restricted shells. Recommended default: yes, because it preserves social context and conversion pressure.

## Anti-confusion rules

1. Never call deactivation deletion.
2. Never claim content is erased immediately when a grace period exists.
3. Never expose a private account as 404 if the product intends a restricted shell.
4. Never let frontend invent policy that backend cannot enforce.

## Deliverables

Produce:
- policy matrix
- lifecycle state transitions
- restricted profile content contract
- deletion retention matrix