Observed since 20 Oct, 18:01 UTC
No superseded metadata states collected. Unchanged observations do not create new revisions.
Safety-first account recovery guidance through official channels.
Account Recovery Assistant is a safe guide for people who lost access to an account, got stuck in multi-factor authentication, forgot recovery details, or need help using official recovery channels.
This is an account recovery helper. It does not hack accounts or bypass security. It helps the rightful owner understand what happened, collect proof, choose the right official process, and avoid mistakes that make recovery harder.
People lose access to email, social media, banking, work, gaming, domain, and cloud accounts. Common causes include forgotten passwords, lost phones, broken authenticator apps, changed phone numbers, missing backup codes, suspicious activity locks, old recovery emails, and business admin turnover.
Official recovery flows are often confusing. Users do not know what information is required, why forms are rejected, or which actions look suspicious. Account Recovery Assistant turns recovery into a guided process: identify the account and failure type, collect ownership evidence, find the official recovery channel, prepare support messages, track attempts, and harden the account after access is restored.
The product must only help the rightful owner or an authorized representative. It must not provide instructions for bypassing MFA, phishing, social engineering, password cracking, device hacking, or session theft. All guidance must use official service procedures.
The first prototype is a small Python CLI and core library. It reads a JSON situation file and prints a safe recovery plan as JSON.
The project now also includes a local web wizard on top of the same engine for the first four canonical incidents.
Run an example:
PYTHONPATH=src python3 -m account_recovery_assistant examples/lost_mfa.json
Print a readable Markdown report:
PYTHONPATH=src python3 -m account_recovery_assistant --format markdown examples/lost_mfa.json
Run tests:
PYTHONPATH=src python3 -m pytest -v
Build a package locally:
python3 -m build
Start the local web wizard:
PYTHONPATH=src python3 -m account_recovery_assistant --serve-web
Or directly:
PYTHONPATH=src python3 -m account_recovery_assistant.web
Supported MVP scenarios:
Example inputs included in the repository:
examples/lost_mfa.jsonexamples/changed_phone.jsonexamples/suspicious_lock.jsonexamples/google_identity_review.jsonexamples/apple_wait_period.jsonexamples/meta_business_takeover.jsonexamples/meta_identity_review.jsonexamples/microsoft_backup_admin.jsonexamples/microsoft_domain_support.jsonThe planner also uses data/service_priorities.json for aliases and official links for the first top-priority services, including Google/Gmail, Apple/iCloud, Facebook, Instagram, Microsoft/Outlook, X/Twitter, TikTok, Yahoo Mail, LinkedIn, and Telegram.
The project now also exposes a normalized incident questionnaire layer for the first high-value web-wizard cases: Gmail MFA loss, Apple trusted-device loss, Meta account hacked, and Microsoft admin lockout.
Each of those first incidents now uses a shared questionnaire contract with stable id, field, answer_type, and required keys so the same flow can drive the CLI today and a future web wizard later.
The recovery knowledge base now carries incident-specific metadata for those first web-wizard cases: ownership evidence, common mistakes to avoid, source notes, verification date, review due date, review cadence, confidence level, and explicit review status.
The Phase 2 and Phase 3 foundation is now product-oriented rather than purely exploratory:
verified, needs_review, or fallback unverified status, with explicit 30-day review cadence metadata.Phase 4 is now started as a local web product surface:
The current MVP now also produces first-approximation recovery guidance instead of only generic checklists:
next_best_action for the chosen incident and answer path;decision_path_id that shows which incident branch was selected;prepare_now list focused on evidence and context to gather before retrying;what_can_make_this_worse list to reduce lockout and support-review mistakes;escalate_when list for cases where official recovery is stalling;expected_timeline estimate based on whether trusted factors still exist.That guidance is now driven by incident-specific decision_paths in data/recovery_playbooks.json, so the first four incidents can be deepened by updating the knowledge base instead of hardcoding every branch in Python.
The current recovery engine already distinguishes several materially different first-pass branches inside the same incident, such as backup-code recovery vs. identity-review recovery for Google, or backup-admin recovery vs. tenant-support recovery for Microsoft.
The main difference is safe navigation: understand the situation, collect proof, use official channels, and protect the account after recovery.
See docs/current-usage.md for the current MVP workflow and user value.
See docs/service-priorities.md for the first knowledge-base expansion plan.
See docs/knowledge-base-operations.md for the incident review policy and freshness contract.
See docs/releasing.md for package and release steps.
See roadmap.md.
Download counts and popularity will appear here as the collector receives them.
| Version | Published | Direct dependencies | Open version |
|---|---|---|---|
| 0.1.0 | 19 Jun 2026 | 0 |
This describes our collected data; it is not a security assessment.
Shared repository data · GitHub
Observed since 20 Oct, 18:01 UTC
No superseded metadata states collected. Unchanged observations do not create new revisions.
package:dab090a6dd5e55ce015fe9877c24771b3b2bec2c18c0da5a110ee4a2587cd1b1