Changelog

Frontend changes

• The checkbox that confirms irreversible account deletion is now explicitly tied to the words describing it, so every screen reader and every keyboard path reaches it the same way. It is the one control on that screen where mishearing what you are agreeing to is permanent.
• Pevidy's own record of what account deletion removes named four kinds of data — your mail, your searches, the official sources gathered for you and the stored copies of them — as having no deletion route yet. All four were already removed with the rest of your account. The deletion was right and only the description of it was wrong, which is the more dangerous way round: somebody checking whether deletion is complete reads the description.
• Deletion completeness is no longer a list somebody maintains. Every table that holds data belonging to an account now has to be shown reachable by deletion, so a new kind of stored data that nothing removes stops the release instead of shipping quietly.
• Deleting one account cannot disturb another, and that is now measured rather than assumed: a second account's data is counted across every table that belongs to an owner, before and after the first account is exported, deleted, restored, deleted again and finally purged. The two counts have to be identical.
• Operational logs can no longer be bypassed. Writing a log line anywhere except through Pevidy's logger fails the build, so no code path can sidestep the rule that keeps the contents of your documents and your mail out of the logs.
• The list of every state an object in Pevidy can be in had stopped being extended, and a third of it was missing. It is now derived from the objects themselves, so a new kind of object cannot be added without appearing there.

Manual review

1. Open the readiness endpoint and confirm the deployment reports healthy with the published revision.
2. Open Settings, find the account deletion section, and confirm that clicking the words beside the confirmation checkbox toggles the checkbox itself.
3. Confirm that nowhere in the interface offers to send, file or submit a form to anyone: this release adds no such action either, and no address in the product reaches one.
4. With an approved synthetic account, confirm the existing vault, source, document, opportunity and admin screens are unchanged by this release.
5. Confirm the changelog lists this entry above the previous one and that no earlier entry was rewritten.

Frontend changes

• An official form Pevidy has captured can now become a prepared form: your own verified details placed into the form’s own fields, ready for you to look at before anything is produced.
• Only values Pevidy can point at a source for are eligible. A value it believes but cannot show you the passage behind is offered for you to confirm; it is never placed on the paper on its own.
• A required field nobody has answered keeps the form open. It stays visible and unanswered, and the form cannot be produced until you settle it — nothing is guessed to make the form look finished.
• You review the form before anything happens. What the official form says and what Pevidy proposes are shown as two separate things, never merged into one list.
• Nothing is produced until you explicitly approve it. Pevidy cannot approve on your behalf, a background job cannot, and a model cannot — there is no path through the system that reaches approval without a person.
• If anything changes after you approve — you correct a value, the authority republishes the form, a document a value came from is deleted — the approval no longer applies and the form comes back to you for review.
• Only after you approve does Pevidy fill the actual PDF, and it does it once. Two clicks, a retry or two servers working at the same time still produce one document.
• Pevidy then reads the produced document back and checks it against what it asked for: every approved value present and correct, every field you left open still empty, and nothing on the paper that you did not approve. If any of that fails, no document is produced.
• Anything that has to be your own act is left to you. A signature is never drawn and a consent box is never ticked, whatever Pevidy happens to know about you.
• The produced form is saved in your vault as your own document, marked as prepared by Pevidy rather than as something official or something you uploaded.
• You can open the exact version that was produced in the viewer and download it through a short-lived link that expires. There is no permanent address for the file.
• Each prepared form keeps its trail back to the official form it was built from, the version of that form, and the passages your values came from.
• Correcting something after a form was produced creates a new version rather than overwriting the old one. The earlier version, its document and its fingerprint stay exactly as they were, marked as superseded.
• Pevidy can email you a link to the finished form. The mail carries a link that still asks you to sign in, never the document itself — an attachment cannot be recalled once sent.

Manual review

1. Open the readiness endpoint and confirm the deployment reports healthy with the published revision.
2. Confirm that nowhere in the interface offers to send, file or submit a form to anyone: this release ships no such action, and no address in the product reaches one.
3. With an approved synthetic account, confirm the existing vault, source, document and opportunity screens are unchanged by this release.
4. Confirm the changelog lists this entry above the previous one and that no earlier entry was rewritten.

Frontend changes

• Pevidy can now read the individual fields of an official form it has captured — what each one is called, where it sits on the page, and whether the form says it must be answered — and treat each one as a separate question to be answered.
• A field keeps the same identity between readings. Two fields with the same label on different pages stay two different questions, and re-reading the same form does not quietly renumber anything.
• Where the form does not say whether a field is mandatory, Pevidy records that it does not know, rather than deciding for it. Unknown is not the same as optional.
• Every value Pevidy proposes comes from something you already have: your profile, a fact it has recorded, a passage in one of your documents, something that happened, evidence you supplied, or something you typed yourself. Nothing is written from anywhere else.
• A value is only marked verified when Pevidy can point at the passage it came from — the document, the page, the words. A value it believes but cannot show you the source of is offered for you to confirm, never presented as established.
• Which of your records Pevidy is even allowed to look at depends on what the field asks. A bank field never opens your health records, and a field Pevidy cannot make sense of opens nothing at all.
• A model may point at one of the values Pevidy already found and suggest reformatting it. It cannot write a value, cannot name a source, cannot mark anything verified, and cannot choose anything it was not shown — there is nowhere in its answer for any of those.
• Reformatting only ever rearranges what is already written: spacing, capitalisation, a date in the form’s own layout, a phone number in international form, one part of a name that is already there. Nothing is completed, translated, looked up or worked out.
• A date written 01/02 is treated as genuinely two dates unless the form says which order it uses. Pevidy asks rather than picking the likelier one.
• An amount keeps whatever currency was written and is never given one it did not have. A bank account number is checked against its own check digits before it is offered.
• A tick box nobody ticked stays untouched. A blank field stays blank rather than becoming “not applicable”, which would be an answer nobody gave.
• Where two of your documents disagree, both are kept and shown, and the field waits for you. Pevidy does not average them, rank them or quietly prefer the newer one.
• Anything that must be your own statement — a consent box, a signature — is always left to you. No document of yours is read as agreement, and no signature is produced.
• Every field shows where its value came from: the document, the page and the passage. Bank details, identifiers and contact details are shown shortened, in the summary and in the source view alike.
• If the document a value came from is deleted, or the authority republishes the form, the decisions resting on it are set aside for review rather than left standing. What was decided, and why, stays readable.
• For each field you can accept what Pevidy found, choose a different value it found, type your own, or reject it. Every one of those is re-checked by Pevidy from scratch — your browser cannot tell it that something is verified.

Manual review

1. Open the readiness endpoint and confirm the deployment reports healthy with the published revision.
2. Confirm that no address in the interface offers to fill in a form, produce a completed document or send anything: this release ships no screen for any of it.
3. With an approved synthetic account, confirm the existing vault, source and opportunity screens are unchanged by this release.
4. Confirm the changelog lists this entry above the previous one and that no earlier entry was rewritten.

Frontend changes

• When a step you are taking needs a particular official document — a form, an authority’s own guidance, a fee table — Pevidy can now record that as an explicit requirement: what kind of document, from which authority, under which country’s law, and why the step needs it.
• A requirement is only created because a confirmed step needs it. A model noticing that a form might be useful is not a reason, and there is nowhere in the record for a model’s confidence to make it one.
• The questions Pevidy asks a search provider are assembled from the requirement itself — the kind of document, the authority, the country — rather than written by a model. Nothing you have typed and no document of yours can end up inside one.
• A model reads each result and says what kind of page it looks like: a form, an explanation, a download page, or something else. It never decides that a page is official, who published it, which version it is, or whether it may be used.
• Before anything is accepted, Pevidy checks the publisher against its own written policy, the authority against the one the step expects, the country, the kind of document, what the file actually is, and whether the version still applied on the day the step is for.
• A copy of a document on somebody else’s website is not treated as the official one, even when the bytes are identical. Where a page came from is a separate question from what it contains.
• Whether a document is current is judged against the date of your step, not against today. A form that stopped applying last month is still the right form for something you did two months ago.
• When a version cannot be read, or when two versions both look current, Pevidy asks a person instead of picking one. There is no ranking, no preference for the newest, and no tie-break.
• An accepted document is captured as a fixed copy and is tied to that exact copy by its fingerprint — not to the address it came from. What you are shown later is the copy, not whatever that address serves today.
• If the authority republishes at the same address, Pevidy records a new version alongside the old one and marks the old one superseded. Nothing is quietly overwritten, and an earlier approval no longer applies to changed content.
• A page behind a sign-in, a payment wall or a challenge is never worked around. Pevidy records what it found and stops.
• Where the document is a form Pevidy can read, it works out the structure — which fields exist, what they are called and where they sit on the page — without reading, choosing or filling in a single value.
• Every accepted document can be traced back through the copy, the check that accepted it, the candidate it came from and the search that found it.

Manual review

1. Open the readiness endpoint and confirm the deployment reports healthy with the published revision.
2. Confirm that no address in the interface asks for, searches for or opens an official resource: this release ships no screen for any of it.
3. Confirm the readiness endpoint still reports search as unavailable in this deployment, and that nothing in the interface offers to search anyway.
4. With an approved synthetic account, confirm the existing vault and source screens are unchanged by this release.
5. Confirm the changelog lists this entry above the previous one and that no earlier entry was rewritten.

Frontend changes

• Pevidy can now notice that a particular question is not answered by anything you have given it. That is decided from your own documents and the records taken from them — not from an impression that something might be missing.
• It will not go looking for something it can already answer. If your own papers, a rule taken from them, or a source it has already accepted and still holds a current copy of answers the question, no search happens at all.
• How much work one question may cost is fixed before the work begins: a set number of searches, retrievals and reasoning steps. The limit cannot be raised while the work is running, and nothing that suggests what to ask can change it.
• Every question sent to a search provider is written by a fixed rule rather than by the model that proposed it. Which country’s law the question is about comes from the question itself, and which sites may be used comes from Pevidy’s own policy.
• A question sent to a search provider never carries personal information. An email address, a telephone number, a bank detail, a postal address or a reference number causes the question to be refused outright rather than tidied up and sent anyway.
• Nothing written on a page can steer where Pevidy looks. An instruction hidden inside a document or an email asking it to consult a particular website is treated as text and changes nothing.
• Sources found this way go through the checks that were already there: the same written trust policy, and the same retrieval and stored copy. Finding something in a search gives it no standing on its own.
• Research ends in one of three ways and always says which: answered, needing a person to look, or unsupported. Finding nothing is a result, not a failure, and is reported as plainly as an answer.
• An answer must rest on a stored copy that Pevidy accepted and still holds as current, identified by its fingerprint. A summary from a search results page can never answer a question, however well it reads.
• Where sources disagree, or the only ones available are out of date, or one was approved by a person before the page changed, Pevidy asks for a person instead of choosing quietly.
• Finished research can be explained: the question, why it was open, the country, which sources it rested on, which version of each, their trust and review state, why it stopped, and what it looked at and set aside.
• What you are shown never includes the model’s private working. You see the question, the checked reason it was open, and the sources — not the sentences a model wrote on the way there.

Manual review

1. Open the readiness endpoint and confirm the deployment reports healthy with the published revision.
2. Confirm that no address in the interface starts, shows or explains a piece of research: this release ships no screen for any of it.
3. Confirm the readiness endpoint still reports search as unavailable in this deployment, and that nothing in the interface offers to search anyway.
4. With an approved synthetic account, confirm the existing source screen is unchanged by this release.
5. Confirm the changelog lists this entry above the previous one and that no earlier entry was rewritten.

Frontend changes

• Pevidy can now retrieve a public source that its written policy has already approved, and keep a copy of exactly what that address served. Until now it could only say who published something; it can now hold what was published.
• A copy is never changed after it is made. If a page changes, Pevidy keeps the new version alongside the old one rather than replacing it — so what a source said in August still has an answer in December.
• Each copy records the moment it was retrieved, the address that was asked for and the address that actually answered. When a link redirects somewhere else, both are kept, because those are two different facts.
• Every copy carries a fingerprint of its contents. Two people can check they are looking at the same text, and a citation points at the copy rather than at a live address that may since have changed.
• Looking again at an unchanged page adds no second copy. Pevidy records that it checked and found nothing different, which is a smaller claim than finding something new and is kept as a separate one.
• Pevidy tracks how long it has been since it last held a source in its hands, and marks a source out of date when that becomes true. Being told by a server that nothing changed is recorded as the server’s word, not as Pevidy having checked.
• Retrieving a source is only ever permitted for an address the policy already approved, and permission is checked again when the answer comes back — so a source withdrawn while a request was in flight is not kept.
• Pevidy will not connect to an address inside a private or internal network, will not follow a redirect off the approved site or down to an insecure connection, and refuses a response that is not what it claims to be, is too large, or arrives compressed.
• A page that asks for a login, sits behind a paywall or presents a challenge is reported as exactly that. Pevidy does not attempt to get past any of them.
• Where a retrieved PDF or image is supported, it can go through the same document processing Pevidy already uses — while staying labelled as external material and never becoming one of your own documents.

Manual review

1. Open the readiness endpoint and confirm the deployment reports healthy with the published revision.
2. Confirm that no address in the interface leads to a retrieved page: this release ships no screen for stored copies, and nothing renders their contents.
3. With an approved synthetic account, confirm the existing source screen still shows a trust decision with its rule and policy version, unchanged by this release.
4. Confirm a source that has never been retrieved still reports its currency as unknown rather than as current.
5. Confirm the changelog lists this entry above the previous one and that no earlier entry was rewritten.

Frontend changes

• An external source is now identified by the exact address it is served from, written in the form that cannot be disguised. A domain built to look like a familiar one is shown to you as what it actually is, and never as the domain it imitates.
• Pevidy records what kind of thing a source is — an authority, a form, a legal text, guidance, provider documentation — together with the jurisdiction and the language it applies to.
• Whether a source is trusted comes from a written policy that is versioned and reviewable. It does not come from where a result appeared in a search, from a page describing itself as official, from the address being secure, or from a model’s opinion.
• Every source shows what Pevidy decided, the rule that decided it and which version of the policy that rule belongs to. There is no badge on its own: a label you cannot check is a label you cannot argue with.
• A source reads as trusted, needs review, rejected or stale, in words rather than colours. A stale source stays visible with its own label instead of disappearing.
• When two sources disagree and the policy cannot separate them, both are shown with the reason it could not. Nothing picks a winner quietly, and the highest search result never wins by being first.
• External material is labelled as guidance and is kept visibly separate from your own documents. It can sit beside your evidence; it never becomes it and never replaces it.
• A decision you record about a source is tied to the exact assessment you were shown. If the assessment changes afterwards, your decision is marked as no longer current rather than quietly applied to something you did not read.
• Every decision is kept. Re-checking a source adds a new record rather than overwriting the old one, so why a source was treated a certain way in June still has an answer in December.

Manual review

1. Open a source address while signed out and confirm it sends you to sign in rather than showing anything.
2. With an approved synthetic account, open a source address belonging to another account and confirm it is not found, exactly as an address that never existed.
3. On a source screen, confirm the trust label never appears on its own — the rule that produced it and the policy version are beside it every time.
4. Confirm a lookalike domain is displayed in its literal form with a warning, and that Pevidy does not describe it as the familiar domain it resembles.
5. Confirm the screen says in plain words that external material is guidance and not your own evidence, and that a source with no retrieval date reports its currency as unknown rather than current.

Frontend changes

• Pevidy can now search the open web for material about a question, through a real search provider, and keep what it finds as candidates you can look at.
• A search carries the context that changes the answer — the language and the jurisdiction it is asked in — so a question about German law is not answered with results from somewhere else.
• Every result is labelled “Discovered — not verified”, and that is the only state a result can be in. There is no official badge, no trust score and no ranking by anything except the order the search engine returned.
• Results are shown as plain text. A page title or summary is what that page says about itself, so nothing from a search result is rendered as part of Pevidy, and none of it can act.
• Links to results open in a new tab and are marked as not endorsed by Pevidy. Pevidy checks that an address is well formed and safe to store, and does not open it.
• Only web addresses Pevidy can safely keep are stored at all: no insecure addresses, no addresses carrying credentials, and a lookalike domain is shown to you as one rather than quietly accepted.
• Your searches are yours. A search belongs to your account, another account’s search is not found rather than refused, and deleting your data removes your searches with it — including an answer that arrives after you asked us to stop.
• When the search provider is unavailable, rate-limited, out of searches or slow to answer, Pevidy says which of those happened instead of reporting an empty result as an answer.

Manual review

1. Open a search results address while signed out and confirm it sends you to sign in rather than showing anything.
2. With an approved synthetic account, open a search results address belonging to another account and confirm it is not found, exactly as an address that never existed.
3. Open the readiness endpoint and confirm external search is listed as a dependency, reporting disabled until a provider credential is configured.
4. With a search present for your own account, confirm every result reads “Discovered — not verified” and that no result is described as official, trusted or checked.

Frontend changes

• Notifications can now reach you by email as well as in the app. Email is off until you turn it on per notification type, quiet hours are respected, and turning it on never mails you anything from before the day you enabled it.
• Every product email is one of ten fixed messages. A subject carries no name, no amount and no document title, because a subject is visible on a lock screen.
• Each claim now has a Conversation screen showing the mail Pevidy has sent and received about it, in order, with the delivery state the mail provider actually reported — Queued, Sent, Delivered, Bounced or Needs reconciliation, and never a claim of delivery nobody confirmed.
• Message content is shown as plain text. Nothing from an email is rendered as a web page, quoted history is separated from what somebody wrote now, and an attachment is shown by name only.
• You can reply from the Conversation screen. The reply goes to that conversation and nowhere else: there is no recipient field, no subject field, and no way to start a message to a new address.
• A reply you receive is placed on the right claim by a code Pevidy issued, not by who sent it or what the subject says.
• Sensitive files are never attached to email. A product email links to Pevidy, and the link opens nothing until you are signed in and still own what it points at.

Manual review

1. With an approved synthetic account, open a claim's Conversation, confirm the messages appear oldest first with truthful delivery states, and confirm no message text is rendered as HTML.
2. Send a reply from the Conversation screen and confirm the screen reports what actually happened rather than claiming the message was delivered.
3. Open a conversation URL for a claim that is not yours and confirm it is not found, exactly as a claim that does not exist.
4. Open an email action link while signed out and confirm it sends you to sign in, then confirm it refuses an artifact that has expired or been superseded.
5. In notification preferences, confirm email is off by default per type and that enabling it does not produce mail about anything from before.

Frontend changes

• The authenticated header now includes an accessible Notification bell with a server-derived unread count and a bounded notification panel.
• Each notification has one canonical Pevidy destination and reflects current authorized domain state rather than embedding an action or external URL in its payload.
• Pevidy now creates deduplicated in-app notifications for actionable missing evidence, review states, ready packages, terminal processing failures, approved account lifecycle events and ready exports.
• Read, Read all and notification preferences are owner-scoped, idempotent and consistent across refreshes without letting duplicate workflow delivery make an item unread again.
• Notification preferences use versioned server settings for supported in-app delivery, frequency and quiet-window metadata, with clear conflict refresh behavior.
• Notification payloads are template-driven and exclude document or email contents, provider or LLM payloads, credentials, signed URLs and arbitrary HTML.

Manual review

1. With an approved synthetic account, open the Notification bell and confirm that unread state, safe item text, one destination and Read all work at desktop and narrow width.
2. Open Notification preferences in Settings and confirm that supported in-app, frequency and quiet-window controls reload authoritative values after saving or a stale-state conflict.
3. Open a stale synthetic notification and confirm that its destination shows current product truth without restoring an old review, package or export state.
4. Do not manufacture notifications, alter preferences or trigger lifecycle events for a real customer solely for publication review.

Frontend changes

• Authorized Support and Admin operators can now use a capability-aware Operations queue with bounded search, filters, correlation, safe job details and truthful attempt and recovery history.
• Pevidy supports explicit Retry, Cancel, Requeue and Mark for Review commands with target scope, structured reason, currentness, idempotency and reconstructable audit lineage.
• Provider timeouts are classified by known side-effect evidence: an unknown external outcome must be reconciled before Retry can become available.
• Requeue creates one linked workflow run instead of copying or manually patching a failed record, so the original run, operator action and new run remain connected.
• Provider health and rate hints remain distinct from Pevidy product quotas, while AP57 reservations are committed, released or retained for reconciliation from verified outcome evidence.
• Operations remains metadata-first and excludes raw documents, provider payloads, credentials, signed URLs and email contents from the default queue and detail views.

Manual review

1. As a normal test user, confirm that no Operations entry is shown and that direct access to the Operations route is denied.
2. With an approved synthetic operator, open Operations and review the bounded queue, filters, one job detail, correlation and the truthful attempt/recovery timeline at desktop and narrow width.
3. Using synthetic fixtures only, confirm that each available recovery dialog names its target, impact and required reason and that stale or ungranted actions are refused after authoritative refresh.
4. For a reconcile-first fixture, confirm that Retry is unavailable until an exact provider outcome is established; do not create or recover a real customer failure for review.

Frontend changes

• Pevidy now resolves every account through one versioned Plan and Entitlement catalog, with explicit limits for documents, storage, active opportunities and metered product operations.
• The Account Plan section shows the current server-assigned plan, included features, real usage, remaining capacity and UTC period reset information without relying on browser-supplied values.
• Quota decisions are atomic and idempotent, so parallel last-unit requests and workflow retries cannot silently exceed a limit or count the same logical operation twice.
• Document, storage, opportunity, AI and Nutrient-backed product paths now return clear, resource-specific quota guidance before an unavailable operation is presented as successful.
• Authorized operators can assign a valid Plan version from Admin Account detail with capability, target, reason, currentness and audit checks, followed by an authoritative refresh.
• Plan downgrades preserve existing resources while preventing new quota-consuming work when current usage is already above the new limit.

Manual review

1. With an approved synthetic account, open Settings and review Current plan and Usage at desktop and narrow width, including included features and any applicable UTC reset date.
2. Use a synthetic near-limit fixture to confirm that a denied document, storage or opportunity action explains the affected resource and real remaining capacity without exposing internal records.
3. With an approved synthetic operator, review Plan assignment in Admin Account detail and confirm that target, current and selected plan, reason and confirmation are explicit before submission.
4. Do not change a real customer plan or consume AI or Nutrient provider credits solely for publication review.

Frontend changes

• The Privacy Center now lets account owners request a versioned data export, follow its truthful lifecycle, and download the completed private artifact before its server-controlled expiry.
• Exports contain a portable manifest, safe account data and referenced files while excluding credentials, session secrets, provider keys and internal storage paths.
• Account deletion now enters a configurable reversible Grace period that revokes sessions, stops new normal background work and allows Restore before irreversible cleanup starts.
• Authorized operators can request exports, start deletion, restore during Grace and initiate verified purge through capability-aware Admin actions with reason and exact-target confirmation.
• Final purge uses the canonical workflow and cleanup registry across relational data, private storage, generated artifacts and derived data, and reaches its terminal state only after orphan verification succeeds.
• Late jobs, callbacks and workflow replays cannot recreate personal data after a completed purge.

Manual review

1. With an approved synthetic account, open Settings and review the Data export and Account deletion sections at desktop and narrow width.
2. Confirm that export status, download availability, expiry, Grace and Restore are shown without exposing storage references, signed URLs or archive contents.
3. In the Admin Account detail for disposable test data only, confirm that lifecycle actions name their target, impact and reason, and that Purge requires exact target confirmation.
4. Do not create a deletion request or execute purge against a real customer account during review.

Frontend changes

• Authorized operators can now open a Pevidy-native Admin Control Center with capability-aware navigation and clear operator context.
• The dashboard, bounded account directory, safe search and filters, and account detail provide truthful status, plan reference, document, storage, session, activity and processing summaries without exposing private content.
• Account lists use stable server pagination and bounded aggregate queries, so the browser never downloads the full account population or issues one request per row.
• Operators with the required capability can suspend or reactivate an account and revoke an individual session through explicit target, impact, reason and confirmation dialogs backed by the existing audited commands.
• Unavailable export, deletion, restore, purge and plan-assignment operations remain visibly unavailable instead of presenting a simulated result.
• Normal users receive no Admin entry, and every Admin read or mutation remains protected by server-side capability, target-scope and lifecycle checks.

Manual review

1. Sign in with an approved synthetic Admin account and open Admin from the User menu; review the dashboard, account directory, search, filters and one account detail.
2. At desktop and mobile width, confirm that Account status and bounded document, storage, session, activity and error summaries remain readable without exposing document contents or session secrets.
3. Using synthetic data only, inspect the Suspend, Reactivate and Revoke session dialogs and confirm that each names its target, impact and reason before submission.
4. Sign in as a normal test user and confirm that no Admin entry is rendered and a direct Admin request remains denied.

Frontend changes

• Pevidy now resolves user, support, admin and named system identities through one server-controlled role and capability contract with default-deny behavior.
• Privileged account suspension, reactivation and session revocation require an explicit capability, an exact target, a bounded reason and a reconstructable audit record.
• Suspending an account immediately blocks its normal sessions and new user-authorized background work; reactivation never restores an old revoked session or bypasses the account lifecycle.
• Client-provided roles, capabilities, account targets and system-actor claims cannot grant authority, and support or admin roles are not wildcard superusers.
• Sensitive document access remains separately capability- and target-scoped, with no view-as-user or impersonation path.

Manual review

1. Sign in as a normal test user and confirm that Home, Vault, Opportunities, Activity, Simulate and Settings remain available for that user's own data.
2. Confirm that the existing Account and Security surfaces continue to show only the current user's profile and sessions; AP54 does not add an Admin Control Center.
3. Review an inactive synthetic account through the established test path and confirm that normal sessions and background actions remain blocked.

Frontend changes

• Pevidy now supports real account registration, provider-verified activation and a safe recovery entry point without exposing whether an arbitrary address has an account.
• Settings uses the existing product shell for owner-safe profile self-service and explains pending verification, active, suspended and deletion-pending account states in plain language.
• Security shows the current account's active sessions and supports revoking one session, signing out the current session and revoking all sessions with immediate Pevidy-side authority checks.
• Profile updates are limited to display name, locale and jurisdiction; account status, roles, plans and ownership remain server-controlled.
• Account deletion can now be requested through an explicit confirmation and truthfully enters deletion pending, which blocks new normal sessions and user-authorized background work.

Manual review

1. Create a test account through Registration, complete provider verification and confirm that Settings reports the account as active before normal product access is available.
2. Open Settings from the User menu, update an allowed profile field and confirm that email, account status, roles and plan are not editable.
3. Open Security, identify this device, revoke another session and use Revoke all sessions to confirm that the current session returns to sign-in.
4. Use the recovery entry with a non-sensitive test address and confirm that the response does not reveal whether the account exists.
5. For an approved synthetic account only, review the deletion confirmation and confirm that the result is described as deletion pending rather than deleted or purged.

Frontend changes

• Pevidy now applies a complete Core security hardening pass across uploads, private owner data, untrusted input, provider failures and API responses.
• Matching, Evidence and Proof reliability now include broader Golden and Non-Golden regression coverage, source-grounding safeguards and deterministic state checks around AI suggestions.
• Provider processing, package generation, Viewer review and secure Export expose clearer failure states without treating an uncertain external result as success.
• Critical lists, searches, activity and workflows have bounded pagination and runtime guards for larger reasonable datasets.
• The complete reset-based Golden Path passed ten consecutive real-provider reliability runs without a failed counted run or duplicate logical effect.
• Navigation, workflow hierarchy, keyboard focus, responsive layouts, loading, empty and error states have received a final product-polish and accessibility pass.

Manual review

1. Use the primary navigation and User menu to move between Home, Vault, Opportunities, Activity, Search, Settings and Changelog at desktop or mobile width.
2. Open an Opportunity and confirm that its current status, Evidence progress, missing information and one next action are clear without exposing internal enum names.
3. Review an available Package in the Viewer and use secure Export; confirm that Signing remains honestly unavailable when it is not configured.
4. Inspect loading, empty and failure states and confirm that Pevidy never presents incomplete Evidence, an unavailable provider or an unknown outcome as success.

Frontend changes

• Product Search finds your own Documents, Opportunities, Activity and Simulations and opens their existing authorized Pevidy destinations.
• Settings shows your current profile and a truthful overview of available and planned product capabilities.
• The Notification Center adds an owner-scoped unread count, safe product links and explicit read controls without automatic notification generation.
• Pevidy is installable as a Progressive Web App with a bounded public offline shell that does not cache private APIs, documents or business commands.
• Manual Event input now uses the canonical Event and Workflow pipeline with retry-safe command identity and honest processing status.
• Email, Calendar, Webhook, website monitoring and External Search are visibly planned rather than presented as connected or active.

Manual review

1. Open Search, enter a term from one of your own records and follow a result to its normal Pevidy destination.
2. Open the User menu and Settings; review the profile projection and confirm Manual Event input is available while future providers are labelled Planned.
3. Open Notifications, inspect the unread state and use an available item to navigate to its authorized product target.
4. Open Manual Event input, submit a non-sensitive event and confirm that refresh shows the existing status without resubmitting it.
5. Install Pevidy from a supported browser and confirm that an offline visit shows only the bounded offline message, never private account data.

Frontend changes

• Package eligibility correction — August 28, 2026: approval, evidence and package-build controls now share one server-validated currentness decision, so stale or incomplete package inputs show a specific review reason instead of a contradictory enabled action.
• Simulate adds a structured experience for explicitly hypothetical scenarios based only on your uploaded documents.
• Document-backed simulated consequences are grouped into clear categories and preserve cautious, conditional wording.
• Source-backed values, dates and deadlines are shown where Pevidy can validate them from the selected document versions.
• View source opens the exact supporting document and location through Pevidy's existing private Viewer.
• Why this appears traces the hypothetical event through the relevant agreement, rule and source without presenting simulation as real Activity or history.
• Processing, review, empty and failure states remain honest when a consequence cannot be fully supported.

Manual review

1. Open an historically approved Opportunity whose package inputs are no longer complete or current; confirm that package creation is unavailable and that Pevidy shows the specific review reason without changing its historical approval or evidence record.
2. Open Simulate from the primary navigation and enter a clearly hypothetical scenario with an explicit date.
3. Review the consequence categories, conditional descriptions and any document-backed values or deadlines.
4. Select a consequence and inspect Why this appears to follow its hypothetical document relationship.
5. Where a source is available, select View source and confirm that the existing Viewer opens the referenced document and page.
6. Confirm that review or unavailable-source states do not claim a guaranteed future or offer real Action or Package controls.

Frontend changes

• Activity adds a chronological, human-readable history of what Pevidy found and what happened next.
• Opportunity Replay presents the same recorded history as a synchronized Timeline and relationship Graph, with details for the selected step.
• Why did Pevidy recommend this? connects recorded facts, requirements, evidence, decisions and state changes without rerunning AI reasoning.
• Supporting information can be opened at its recorded source location through Pevidy's existing private Viewer.
• Historical package versions, approvals, exports and available signing history remain attached to the version that was recorded at the time.
• Partial or unavailable historical references remain visible as bounded gaps instead of being replaced with current information.

Manual review

1. Open Activity from the primary navigation and review the chronological account history.
2. Open an Opportunity and select Why did Pevidy recommend this? to inspect its Replay Timeline, Graph and selected-step details.
3. Select different Timeline steps and Graph nodes and confirm that the same historical step remains selected across the Replay surface.
4. Where a supporting source is available, select View source and confirm that the existing Viewer opens the recorded owned document and location.
5. Review package, approval and export history where present; Signing remains unavailable when the deployment has no signing capability.

Frontend changes

• Live stability correction — August 27, 2026: Opportunity Workspaces can be opened again from the Opportunities overview across the currently supported states.
• Source review now receives the configured browser-safe Viewer authorization in the production build, and opens available owned documents at a readable full-row size in the existing private Viewer.
• Deployment now applies checked-in database updates before a new application revision begins serving, preventing newer Workspace projections from running against an older schema.
• Package Ready now reports that Signing is currently unavailable for this deployment instead of presenting a simulated signing flow.
• Review package continues to open the exact generated package version in Pevidy's existing private Viewer.
• The Signing review surface remains disabled and exposes no Draw, Type, placement or confirmation controls while the capability is unavailable.
• Secure Export remains available for the exact authorized unsigned package version under the existing package-state rules.
• Unavailable Signing never fabricates a signed package, a Signed state or a successful signature result.

Manual review

1. Open Opportunities and open each listed Opportunity; confirm that its Workspace header, status, readiness and available actions render without the generic error page.
2. From an Opportunity with an available source, select View source and confirm that the document becomes ready at a readable width in the existing Viewer.
3. Open an Opportunity with a generated current package and find the Package Ready section.
4. Select Review package and confirm that the exact package opens in the existing Viewer.
5. Verify that Signing is described as currently unavailable and that no signature or confirmation control is active.
6. Refresh Package Ready and confirm that Signing remains unavailable rather than becoming enabled from browser state.
7. Where the package state permits it, select Export and confirm that the existing unsigned package download still works.

Frontend changes

• Generated opportunities now show a dedicated Package Ready view with the server-provided package version, generation time and available counts.
• Package contents are listed in their authoritative order so the final claim form, letters, index and supporting documents can be understood before review.
• Review package opens the selected generated package version in Pevidy's existing private Viewer.
• Current and out-of-date package states are shown explicitly; an eligible out-of-date package can request Generate new version and reports progress or failure honestly.
• Export explicitly downloads the exact authorized package version as a private PDF instead of silently switching to a newer version.

Manual review

1. Open an Opportunity that has a generated claim package and find the Package Ready section.
2. Verify its version, current status and ordered Package contents.
3. Select Review package and confirm that the final generated package opens in the Viewer.
4. If the Opportunity already has an out-of-date package, verify the warning and the Generate new version action without changing production data just to create that state.
5. For an eligible current package, select Export and confirm that the downloaded PDF is the package version shown on screen.

Frontend changes

• Approved opportunities now offer Build the claim package as an explicit action.
• Package preparation shows an honest queued or in-progress state backed by the server workflow.
• Pevidy creates the Claim Form, Cover Letter and Evidence Index, then assembles them with the approved supporting documents into one final PDF.
• Completed opportunities show Package generated and can open the final package in the existing private Viewer.
• A failed package run stays non-generated and reports the failure without showing a finished package early.

Manual review

1. Open a current approved Opportunity and select Build the claim package.
2. Confirm that package preparation is queued and no completed state appears before the workflow finishes.
3. When Package generated appears, select Open package and inspect the Claim Form, Cover Letter, Evidence Index and supporting evidence in the Viewer.