What this is

You feed manifest-identity the export files your providers already produce: a record of every identity in an account, an organization, a cluster, a project, or a tenant at one moment. It keeps every import and never edits an old one. When you open the inventory, it works out each identity's situation at that moment: compare the newest import with the history, add what people have recorded, and show the result. No status is ever stored, so no status can go stale or be quietly changed; the answer is recomputed from the evidence every time you ask.

Beside that observed record it keeps a second one that no export can supply: what each identity is supposed to hold, said by a named person, for a period, with an owner. The difference between the two records is what the product exists to show, and the review campaigns exist to put each difference in front of the person who can answer it.

People supply what the files cannot: who owns this identity, which one is suspicious, which one was reviewed and found fine, which access was meant. Each of those records is saved with who said it and when, and the same database action that saves it also writes the audit line, so a decision cannot exist without its record. Reports and exports come from the same computation the screen shows, so they cannot disagree with it. And in version one the tool never connects to any provider: files come in, reports go out, and nothing else moves.

What it does

Each feature in three lines: what it does, why it is built that way, and what proves it.

• Reads seven providers natively and any other through a table. AWS from its two export files, GitHub, Google Cloud, Azure and Entra, and Okta from one document each assembled from the provider's own API objects, Kubernetes from one kubectl dump, Active Directory from a document of the directory cmdlets' objects or from the SharpHound collector's zip, which adds who can obtain what through a control right; every other provider from a spreadsheet of who holds what, read through a mapping of its own columns. Each provider's vocabulary ends at its parser and the rest of the product never learns it, so the seventh provider is a parser and not a rewrite (D-071, D-076, D-079 to D-084). Proven by one test file per provider and a generated sample estate for each, imported by the demo.
• Derives every identity's state at read time. Owner, last use, second factor, what it holds now and what it can obtain, through which group or trust, and the findings that follow, computed from the whole history every time. Its credentials are read in nine kinds (access key, password, certificate, signing certificate, client secret, token, SSH key, Kerberos key, API key), each with its age and last use, and each identity is classified from their shape as a person, a service, a workload, an application, a group, a role, an external identity, or unknown (D-056). Nothing derived is stored, so nothing can drift or be edited (D-006). Proven by the derivation and finding suites and by the sample estates producing every finding.
• Twenty findings, each with its reason. Administrator equivalence judged by capability rather than name, escalation paths, keys past their age, identities nobody uses, trusts open to the world, groups nobody owns. Each names the rule it applied and the evidence, because a finding a reviewer cannot check is a rumor. Proven by test_findings.py and test_privilege.py.
• Access as it actually arrives. A grant records its route, hop by hop, through a membership, a trust, a delegation, and its mode: standing, eligible, or session. The page separates what an identity holds now from what it can obtain, which is what makes just-in-time access reviewable rather than invisible (1.6). Proven by test_paths.py.
• Relationships and definitions as things to authorize. A trust into a role is a door someone can authorize; a custom policy or role is a definition someone can authorize at a version, and one that changes afterwards names what it gained (1.6, 1.7). Proven by test_delta.py and test_role_definitions.py.
• The authorization record. What an identity may hold, written by a named person from the session and never from a form, with an owner who is never a lone individual, an expiry the clock enforces with no job, and a reason; append-only, superseded rather than edited, revoked with a reason rather than deleted (D-073). Proven by test_authorizations.py and the matrix walk.
• Two doors into that record. A form that prefills from what is observed, and a file door that reads an organization's own spreadsheet of approvals through a mapping of its columns, with a dry run that shows how the system read it before anything is written (D-074). Proven by test_csv_import.py and test_from_observed.py.
• The delta, stored nowhere. Nine classes of difference between held and authorized, each carrying the time each side was last heard from, because a stale side makes a difference look like agreement. Proven by test_delta.py and the mutation that removes the central comparison.
• Review campaigns driven by the calendar, the delta, or expiry. A frozen population, one decision per item with no bulk certification, recommendations with their reasons, the changes since the last certification, insufficient evidence as a recorded outcome, and an evidence export with the audit chain's head in it (D-039, 1.8). Proven by test_campaigns.py.
• Alerts that are records first. A revocation recommended, an authorization approaching expiry, a difference for an owner to answer: each recorded, each delivery recorded per recipient, sent through one interface that records rather than sends until a provider is chosen, a failed delivery recorded as failed (1.9). Proven by test_alerts.py.
• A read-only API under integration tokens. Identities from a cursor, the delta, and a change feed over the audit record, so a ticketing or monitoring system follows decisions as they happen; tokens are minted once, revocable, and budgeted each (1.10). Proven by test_api.py.
• Governance on identities and groups. Owners, purposes, flags, and attestations, attributed and audited, clearable, with an assigned owner answering the unowned finding and a disagreement with the provider's tag surfaced (D-019). Proven by test_governance.py.
• Scoped authority. A user holds a role at a place in the provider tree and can act on that place and everything beneath it, so an operator for one account is not an operator for another (D-072). Proven by test_scope.py and the mutation that widens the check.
• A page proven by use. One document, no build step, every value rendered as text under a content policy that forbids inline script; the detail opens beside the list, every list has a skeleton and an empty state, both themes pass a contrast check computed from the stylesheet's own tokens, and a real browser drives it in the pipeline (D-036, D-075, D-077). Proven by test_frontend.py and test_browser.py.
• Reports and exports that cannot disagree with the screen. The self-contained risk report, CSV and JSON with the spreadsheet exit neutralized, and the per-campaign evidence export, all from the same computation the page shows (D-040). Proven by test_reports.py.
• Sample estates, generated and checked. One per native provider, three months each, built to trigger every finding and every class of difference, regenerated by a test so the shipped files and the generator cannot drift; nothing about anyone's real estate is ever published. Proven by test_sample_data.py.
• A demo that shows the day after. The demo command writes the authorized record the way an administrator would have, through the same doors, so the delta shows every class of difference with believable counts and the campaign carries a mix of recommendations (D-085). Proven by test_demo.py, which also holds that a second run writes nothing.

What it is not

Stated as firmly as what it is, so the tool is not asked to be something else:

• Not a provisioning tool. It never grants, revokes, or writes anything to any provider; a revocation it recommends becomes a work item for a person (D-024).
• Not a connector. In version one it holds no provider credential and never connects; files come in and reports go out.
• Not a secrets manager, an identity provider, a security information and event management system, or a ticket system. It feeds all of them through its exports and its read API, and it replaces none of them.
• Not a judge. It recommends with its reasons and a named person decides, every time.

---