Work proof shouldsettle an argument.It should not createa new risk.

A Human Agent is limited to that person's work. An authorized owner or reviewer can reach the company records needed to review it.

Protected records remain subject to access checks beyond what the page displays.

Authorization follows the work, not just the account. IPI checks the company, the person’s role, and that person’s relationship to the protected work before returning it. Being signed in is not enough. If the request is outside that person’s authority, the data stays unavailable.

Hiding a button is not security. An unauthorized request must still be refused.

Inactive sessions end automatically. Signing out clears signed-in state.

Dynamic HTML passes through a sanitizer before it reaches the page.

IPI also keeps sensitive execution paths out of the browser application. Privileged operations, provider credentials, payment authority, and other server-only capabilities stay behind server boundaries. The production build checks that those boundaries do not accidentally cross into browser-delivered code.

Release checks are designed to catch changes that reopen common script-injection paths.

The rule is simple:

A sentence from a user should stay a sentence. It should not become code.

Access to proof follows the work it belongs to. Reviewers can reach evidence needed for authorized review, while a Human Agent remains limited to that person’s own work. Once proof becomes part of the committed record, later evidence is handled as a new version instead of silently replacing what was originally submitted.

File delivery remains behind protected product controls rather than public links.

IPI does not hand an outside model unrestricted access to company state. Provider requests are assembled for a defined task, bounded before they leave the server, and separated from the credentials and private storage information that make the underlying system work. The model receives what it needs to perform the requested job, not authority over the system around it.

Proof is not exposed through a public link.

A success screen is not enough to activate a paid plan. IPI waits for a signed Stripe message and confirms that the payment is paid before changing access.

The browser cannot declare its own purchase successful.

IPI guards important decisions against duplicate processing.

A retry should not become a second decision. Important transitions are designed so that repeating a request does not quietly duplicate the consequence behind it. The record remains tied to the action, the people involved, and the decision that actually occurred.

Notification delivery is kept separate from the underlying work record, so a delivery failure does not alter the saved decision.

IPI builds and checks the final public artifact as part of release.

Those checks extend beyond whether the application still runs. IPI tests the boundaries around protected data, browser rendering, proof access, session behavior, external-provider handling, payment authority, and what is allowed to enter the public browser build. Security regressions are tested against the same boundaries the product relies on in normal use.

Changes that fail a protected-boundary check are blocked before production.