Tokens & playbooks / Trust design patterns

IF Design Patterns Catalogue

Make data access and automated decisions understandable.

Documentation reviewed

Source review
Oct 18, 2026

Understand the resource

What it is.

IF curates service-design patterns concerned with trust, information and user control. Current examples include explaining AI capabilities, changing outputs and controlling the level of automation.

When it is useful

You are designing permissions, consent, account access or an AI-assisted workflow.

A proposed application

Put it to work.

This example illustrates a possible use. The proposed workflow and expected result are separate from the bounded checks recorded below.

Try this

Add a plain-language preview of what an assistant can change, then provide a review step and a way to change the automation level.

Result to aim for

A more explicit permission and control flow to test.

Before you start

What you need.

A map of the real data flow, permissions and available user controls.

The practical boundaries

What to watch for.

These are design patterns, not proof of legal compliance or user trust.
A clear screen cannot compensate for hidden backend access or ineffective controls.

Review record

What we could establish.

Public primary documentation reviewed. See the account-free evaluation for executed checks and remaining workflow limits.

Source coverage and runtime coverage are separate

The source-review notes describe documentation and identity. The account-free evaluation below records exactly which public interaction or local fixture was checked, what happened, and what remains untested.

Check current access, terms, licensing and data handling before using a resource with your own material.

Runtime and security evaluation

What the evaluation covers.

Bounded runtime checkedAccount-free · Oct 19, 2026

The capabilities-and-limitations pattern opened with description, advantages, limitations and examples. Pattern browsing worked without submitting information.

Methods: Public HTTP response · Public browser sample. A completed check covers the stated sample; it is not a safety certification.

Target: https://catalogue.projectsbyif.com/
Version or capture: Unversioned public page observed on 2026-10-19
Integrity scope: sha256:ed57a6c386c40261dab9da210a9a8c9a30bb6b5c32c70d30baa8f6e6b087673b — initial HTTP 200 response body only; not whole-application integrity.

Test conditions

Chromium 155.0.8059.82, 1365×900 desktop viewport.
Separate fresh, ephemeral browser contexts for entry and interaction; no owner profile, credentials or stored session.
Only GET/HEAD network requests allowed; forms, downloads, WebSockets and service workers blocked. Some analytics endpoints also blocked.
Short bounded waits; no mobile, assistive-technology, cross-browser or performance certification.

Individual checks and observations

Public HTTP response
pass
Public HTTP response: Anonymous GET with redirects followed, response-body SHA-256 and selected security-header summaries; no cookies retained.
Observed: The standalone client received 200 at https://catalogue.projectsbyif.com/. This establishes response delivery only.
Fresh browser entry
pass
Public browser sample: Open the catalog URL in a new anonymous Chromium context with read-only network guards and no inherited profile.
Observed: The document returned 200 and identified itself as “Design Patterns Catalogue”. 203 image elements were present; no account was used.
Observed public sample or navigation
pass
Public browser sample: Follow the observed Show capabilities and limitations link to https://catalogue.projectsbyif.com/patterns/show-capabilities-and-limitations.
Observed: The destination returned 200; title: “Show capabilities and limitations | Patterns Catalogue”. 4 page image elements had decoded during the bounded wait. This count is not a catalog size or performance benchmark.

Security findings and boundaries

Passive inspection of the initial public document’s response headers and anonymous browser request hostnames, with read-only guards. No source exploitation, account access, dependency audit or private data.

Observed · info

Public response protections

The initial browser page used HTTPS. Its response included HSTS. An enforcing CSP response header declared default-src, script-src, style-src, font-src, img-src, connect-src, form-action, base-uri, object-src, frame-ancestors, upgrade-insecure-requests; it also contained unsafe-inline. X-Frame-Options was DENY. This records the sampled response only; meta policies, backend authorization and exploit resistance were not assessed.

Observed · info

Request surface in the anonymous visit

IF Design Patterns Catalogue attempted requests to 1 additional host, including plausible.io. Host counts include requests stopped by the test guard; they do not establish what data a service retained.

Practical advice · caution

Before using this reference

Use the pattern to make an AI feature’s boundaries legible, then test the explanation with the people who must rely on it.

Practical caveats

Use the pattern to make an AI feature’s boundaries legible, then test the explanation with the people who must rely on it.
These are design patterns, not proof of legal compliance or user trust.

What remains untested

No service using the pattern was implemented; consent, authentication, backend permissions and legal compliance were not assessed.
Results describe the observed public pages and a bounded action, not the entire product or the referenced designs.

Security limits

No authentication, authorization, tenant separation, data retention or backend handling was tested.
Header presence or absence is a sampled configuration observation, not a security certification or an exploit finding.
0 blocked-request records were retained across entry and interaction checks. Guards may alter normal page behavior; the logs do not represent unrestricted traffic.

Evaluation sources

Download this evaluation record (JSON)

Follow the evidence

Sources and further reading.

Primary product page

Keep exploring