Decide what recorded content may be used for

A content policy answers one question per project: what may this project's recorded content be used for? You set it in the Console: open Privacy (/privacy) and choose the Content policy tab. See the Console guide. Your agent can read it and, with the right permission, change it through MCP or the CLI.

It is a grid. Seven kinds of content:

• Model transcripts — prompt and completion bodies.
• Tool call arguments — the arguments and results of tool and MCP calls.
• Session snapshots — browser session-replay recordings.
• Native structural recordings — separately governed native boxes and declared actions, with no screenshots or raw input.
• Person properties — the property bag on a person, such as a name or plan. An email address in it is already stored as [REDACTED], whatever this policy says; see What Anectico redacts and withholds.
• Account properties — the separate property bag on a business account or group, such as a contract value or account tier.
• Agent memory — what a memory operation itself wrote or returned. A retrieval step's returned documents are a model input, not memory, and are governed by Model transcripts instead — see Memory provenance and quarantine for the identity and labelling workflow built on top of this class.

Against four boundaries:

• Recorded — written down at all.
• Shown to a reader — served to somebody asking for it.
• Sent outside Anectico — included in a bulk export. The API calls this boundary export.
• Sent to a model — handed to an evaluation model, which may be a third party. The same boundary covers the small typed judgments the platform makes continuously rather than on demand, which are also answered by a third-party model, and a class denied here is never sent for any of them. Today there are four such judgments. The ranking of anomaly findings sends none of the seven content classes above: a ranking request carries the metric name, the service name, the observed value, the expected band and recent numeric history, and no metric attributes at all. The labeling of repeated log templates sends none of the seven classes either: it carries the normalized template text — the recurring shape of a log message, with the values in it already replaced by placeholders, never a raw log line — together with that template's level and service name. The tracking-plan "did you mean" suggestion sends none of the seven classes either: it carries the observed event name or property key and the plan's declared names of the same kind, never an event property value, and a custom property key is only considered for a request that already holds content access to that project. The judgment of an Issue — how serious it is right now and which part of your application it comes from — sends none of the seven classes either: it carries the Issue's title, which is the error message already truncated and with values such as email addresses and card numbers replaced, its error type, the service that raised it, the level your code reported, and its occurrence, affected-customer, hourly, release and regression counts. Never a message body, a stack trace, a breadcrumb, a request header, custom data, or any customer identifier.

Each cell is Allow, Metadata — you may know the content exists and how large it is, never its bytes — or Deny.

Sharing aggregates outside your organization

One more cell sits beside the grid: Aggregate results — Shared outside your organization. It decides whether a page you host may be granted a saved aggregate result of this project to show its visitors (see Authentication). It is Deny until you change it — a new or existing project shares nothing — and it takes only Allow or Deny. Allowing Shown to a reader for any kind of content never allows this cell: reading inside your organization and showing numbers to anyone who opens a page are different decisions. It is enforced: while it denies, no grant can be created. Aggregate results meet no other boundary, and no other kind of content can be shared this way.

Ask your agent

"Show me the content policy for the checkout project. Which cells are Deny?"

"List what the policy has refused in the last week at the export boundary."

Job	MCP tool or action	CLI command
Read the grid of one project, or of every project	get_content_policy, list_content_policies	anectico content-policy get, anectico content-policy list
Replace the grid	set_content_policy	anectico content-policy set --expected-version <version> --file policy.json --yes
Read or replace the retention windows	get_content_retention, set_content_retention	anectico content-policy retention get, anectico content-policy retention set --file retention.json --yes
Read what the policy refused	list_content_access_audit	anectico content-policy access-audit
Erase one person's content now	delete_content	anectico content-policy erase <content-class> <subject-ref> --reason <text> --operation-id <uuid> --yes

Reading needs governance:read. Changing needs governance:write, which is owner- and admin-only. The MCP write tools preview first and apply with the returned confirm_token; see MCP tools.

Native recording privacy

Native structural storage, reads, recorded steps and read-only proof viewing are implemented under the approved contract. Optional Android and iOS recorders and React Native and Flutter adapters have separate source controls. Source and host tests do not establish device or simulator support, release performance or recorder-to-storage playback. Capture stays off without current native capture settings, native store permission, independent consent and separate upload authority. Inspect your deployment's capabilities before sending native settings. Browser replay permission grants no native content permission. The replay_native class starts denied for storage, reading and export. Native content never transfers to a model. An export allow does not add raw recordings to a person archive.

Native structure contains boxes and bounded declared actions, with no screenshots, typed input, raw accessibility text, images, network bodies or console data. Declared labels remain untrusted application evidence. Unsupported regions and pauses are gaps. Capture needs an explicit current application replay owner and independent replay consent, including when analytics is disabled; a previous analytics identifier supplies neither. Owner switches and reset rotate before another person's frame. Local withdrawal purges unsent bytes and does not prove server erasure.

Your agent uses get_capture_settings, update_capture_settings, get_content_policy and set_content_policy, or anectico capture-settings get, anectico capture-settings set, anectico content-policy get and anectico content-policy set. A supplied native_replay is a complete section replacement; omission keeps it and unrelated browser choices. Settings bind the project and exact capture revision, expire within 60 seconds and can only narrow local permission, masks, blocks and ceilings. Read both revisions, preview the exact project and change, obtain confirmation, apply the same arguments with the returned confirmation token and expected revision, then read back. Capture reads need ingestion:pipelines:read; changes additionally need ingestion:pipelines:write. Content reads need governance:read, writes governance:write; a full MCP write preview also needs the read grant and mcp:write.

Native-only retention executes separately from browser retention. Person, project and organization erasure removes every retained reconstruction and associated upload receipt within its stated reach. Unlinked replay owners need the authorized explicit-identifier workflow. Evidence cannot outlive an erased, expired or revoked source. Person archives include permitted recording metadata with format and version while excluding raw browser and native content. Disconnected devices and already delivered external copies are outside a server erasure completion claim.

A native upload uses separate project-bound replay_upload authority with only replay:write; it cannot read recordings, change policy or act as an agent. The application also needs its separate mobile configuration credential. An accepted upload receipt proves admission only; independent retained-content reads are needed before claiming a recording exists or played. No price, allowance or device performance claim follows from these engineering limits.

What your agent gets back

A read returns every cell, denied ones included, with the version a later write must quote. The refusal record returns entries, newest first, that name the kind of content, the boundary, the reason and who was asking. It never returns content.

Open the proof

The content policy has no proof page. The Console tab shows the grid and lets you change it; your agent cannot widen the policy unless its key holds governance:write.

Read this before you rely on a cell

The table distinguishes controls that enforce a current flow from boundaries with no content flow yet. Native storage and reads enforce their own policy independently of browser replay. Enforcement does not establish device or recorder-to-storage qualification. The three possible states are:

Marker	What it means
Enforced	A denial here changes what the product does.
Not enforced	Your choice is recorded and audited, but it is not yet the control deciding this path.
Nothing to gate	No content of this kind crosses this boundary at all, so the cell would change nothing however it were wired.

Here is the whole grid as it stands:

Content class	Recorded	Shown to a reader	Included in an export	Sent to a model
Model transcripts	Enforced	Enforced	Enforced	Enforced
Tool call arguments	Enforced	Enforced	Enforced	Enforced
Session snapshots	Enforced	Enforced	Enforced	Nothing to gate
Native structural recordings	Enforced	Enforced	Nothing to gate	Nothing to gate
Person properties	Enforced	Enforced	Enforced	Nothing to gate
Account properties	Enforced	Enforced	Nothing to gate	Nothing to gate
Agent memory	Nothing to gate	Nothing to gate	Nothing to gate	Nothing to gate

Raw native recordings have no export flow and never transfer to a model; permitting export does not put their bytes in a person archive.

Agent memory has no producer at all, so every one of its cells is already true. Documents that a retrieval or search step pulled in are recorded as part of the model transcript and are governed by that row, not by agent memory.

Session snapshots and person properties reached this table last, and two details of how they bind are worth knowing before you set either to Deny:

• Denying session snapshots at "Recorded" stops recordings being kept at all for that project; the browser SDK's uploads are refused rather than accepted and discarded. Denying them at "Shown to a reader" refuses playback with an explanation rather than showing an empty timeline. What a session was linked to — the errors and product events that happened during it, and the fact that a session of a given length happened for a given person — is not the recording and stays visible.
• Denying person properties at "Recorded" drops the property values on an identify() call. It does not stop Anectico identifying the person: the identity, the merge of an anonymous visitor into a known one, and every link from that person to their sessions, errors and traces all still happen. Clearing a property is never refused. Denying them at "Shown to a reader" leaves the property bag off each person, per person, according to the project that person belongs to.

"Recorded" reaches the context you attach to an error, too. Tags, extra data and captured request headers on an error report are your own bags of keys and values. A field you name after a model-content convention holds the same bytes the policy governs on a span, so a Deny at Recorded drops it from the error and from its issue and says which fields it dropped. Everything else you sent is untouched. anectico.content.* is a reserved key prefix in every bag Anectico stores — those are the fields it uses to tell you what it withheld, so a key of your own with one of those names is dropped rather than stored.

Both boundaries reach the properties on a product event. The property bag you send with an event is your own bag of keys and values on the same terms. Recorded drops the fields named after a model-content convention before the event is written. On Shown to a reader, a credential below the recorded-content tier receives only attribute keys Anectico knows are operational metadata; an unrecognized key is withheld because its value could be content from a convention introduced after this release. This applies per event and per project on both a person's and an account's activity timeline. The event itself, its name, time, person and session links stay visible.

A nested field is a field. Property bags nest, and so do attribute values — an object or a list under a key of your own. Both boundaries look inside them: a field named after a model-content convention is governed wherever it sits, not only at the top of the bag. The fields beside it survive, including the key it was nested under, so denying one nested field never costs you the object it lived in. A structure Anectico cannot read all the way down — nesting deeper than 32 levels — is refused rather than passed through, because a level it cannot inspect is a level it cannot decide.

The same read rule applies wherever raw telemetry attributes are returned: span attributes, resources, span events and links; log attributes and resources; metric exemplar attributes; custom metric labels; and metric labels on unified-search results. Known operational fields such as route, status, service, model name and token counts remain visible. An unfamiliar field is recoverably withheld rather than guessed safe.

Withholding is explicit in the returned bag. anectico.content.withheld names fields omitted because the credential lacks the recorded-content permission; anectico.content.policy_withheld names fields refused by this project's policy; and anectico.content.not_stored records fields that were never written. Each names the fields it refused; a field that was nested is named by its full path from the top of the bag (http.route.gen_ai.prompt.0.content), so you can see not only what is missing but where the hole is. A policy that cannot be confirmed is treated as a policy refusal at read time. If the credential has the recorded-content permission and the project permits both model transcripts and tool arguments at Shown to a reader, an otherwise unfamiliar key may be returned.

No model is sent person properties or account properties. The automatic quality checks read model transcripts and tool call arguments, and the typed judgments listed above send none of the seven classes. So both of those cells in the Sent to a model column have nothing to gate. Like every cell they are stored and audited with the rest of the grid, and they are independent of each other: a person's email address and an account's contract value are separate disclosures.

A promoted evaluation case is refused rather than trimmed. Promoting a production agent run into a dataset governs the run's recorded content as usual. The expected and metadata documents you send with it are treated differently: if either carries a field named after a model-content convention your project refuses at Recorded, the whole promotion is refused and nothing is written, naming the document and the field. A dataset version cannot be edited once written — that permanence is what makes a result citing it mean something — so quietly dropping a field would leave a specification you did not author, scoring differently for ever. Refusing costs you one edit; you are still holding the document. Reading a case back, or replaying one in the sandbox, is governed at Shown to a reader: the frozen run keeps its shape without the recorded bodies, and the two documents you supplied are withheld whole with a note saying what was refused and why.

Denying person properties at "Shown to a reader" has two knock-on effects the grid does not show: people search stops matching on property values for that project (searching by any identifier you sent with identify() still works), and audiences defined by a property value stop refreshing, because computing one means reading those values. Audiences defined by behavior are unaffected.

When a cell moves between states, the product's marker moves with it and this page changes in the same release.

Denying at "Shown to a reader" also empties two other boundaries

Included in an export and Sent to a model are both assembled from the same read. So a class you deny at "Shown to a reader" is already gone before either of their own decisions is consulted — whatever those cells say.

The product warns you at the moment you set it. The composition runs one way only: denying at "Included in an export" leaves reading untouched.

Leaving the downstream cells on Allow after denying the read is not harmful, but it records an intent the project will not actually have. Set them to match what you mean.

Recording is the boundary you cannot undo

The other three withhold a copy of content that is still recorded, so a denial there is reversible — widen the cell and the content is served again. Recorded means the bytes are never written, and nothing brings them back.

That asymmetry runs the other way too. If Anectico cannot read your policy at the moment content arrives, it keeps serving the last answer it successfully read, so an explicit refusal of yours stays in force through an outage. A project that has never been configured is answered from the platform default until its own policy is written — which happens within about fifteen minutes of the project being created — because refusing those minutes would destroy a new organization's content and answer the same project two different ways.

Browser consent before collection

Browser consent is controlled in your application, before data reaches this project policy. In the Console, the Browser capture tab of Privacy sets what the browser SDK may capture; see Ingestion pipelines. Use one createCollectionController() with initBrowser, AnalyticsClient and startReplay. Diagnostics, performance, product events and replay each start denied until explicitly granted. Withdrawal stops the affected collectors and discards their unsent queues. Already-dispatched requests may still arrive; use the applicable deletion workflow for stored data.

Replay console and network capture also require their corresponding grants for diagnostics and performance. A project content-policy setting cannot grant browser consent, and a browser grant does not bypass the project policy or credential permissions. See the working browser consent and Web Vitals example.

Editing it

A save replaces the whole grid, not the cell you touched. That is deliberate: a partial save cannot express the removal of a permission, and "just change the one I care about" is how an older grant survives an edit nobody noticed. The Console builds that grid from the policy it reads. If the API introduces a content class before the Console has a specific name or enforcement description for it, the Console still shows the row and sends its existing decisions back unchanged.

Every save carries the version you were looking at. If somebody else changed the policy while you had the page open, your save is refused and you are told to reload rather than silently discarding their tightening.

A change takes up to 30 seconds to apply everywhere.

The effect is retroactive at read boundaries. In particular, a finished export that contains recorded content is not a standing grant: every retry and download asks the current Sent outside Anectico cells again. Tightening them holds the existing file back without rewriting or deleting it; widening them can make that same file available again. If the current decision cannot be confirmed, the transfer is temporarily refused.

Retention is a separate limit. An ordinary telemetry export remains bound to the source window under which it was created. A source erasure, or a source window the current retention no longer covers, requires a new export; loosening content policy or increasing retention cannot renew that old binding. Its content also expires from the original source timestamp, using the shorter of the transcript and tool-argument retention windows; creating the file does not restart that clock. Content-retention configuration changes require a new job for ordinary exports created with the content entitlement. See Save and export data.

What the policy has refused

A refusal is invisible by design — the content simply does not travel — so the organization keeps a record of them. Every time this project's policy withholds content at a boundary, it writes one entry naming the kind of content, the boundary, why it was withheld, and who was asking. That is the answer to "why did my export come back short", and to "has this control ever actually done anything".

Three things about it are worth knowing before you read one.

It records refusals, not access. A permitted read writes no entry. Every successful view of a trace, a log line, a profile or a recording passes this control and is allowed, so recording those would mean an entry per view of anything — a second stream of data about the fact that nothing happened. So this is not an access log and it cannot tell you who has read a given person's content; it tells you what your policy has stopped.

"Withheld everything" and "withheld the content but kept the summary" both count. The second looks like an allow in the entry, because the item's existence and size did travel — but the bytes you asked for did not, and that is what you are looking for.

One refusal is one entry, however many times it was attempted. An export that was refused, failed for an unrelated reason and ran again is one refusal in this record, not two — so a count here is a count of what your policy stopped, not of how many times the organization tried. A genuinely separate attempt on a different item is its own entry, and a refusal whose reason changes — your policy tightened between two runs, say — is a new entry too, so the record never keeps asserting a reason that has stopped being true.

Entries carry no content of their own. The kind is a name; the entry exists precisely because the content did not move.

Permissions

Reading a policy — and the record of what it has refused — needs governance:read, which every role from viewer up holds: the people a disclosure control protects have to be able to audit it, and neither the grid nor the refusal record discloses content of any kind.

Changing one needs governance:write, which is owner- and admin-only. Widening a content policy is the broadest disclosure act the product offers: one change can make every transcript in a project readable, exportable or sendable to a model, retroactively, for every credential that already holds the matching content permission.

The policy and the permission compose by taking the stricter of the two. The policy answers whether these bytes may cross this boundary at all; a credential's content permission answers whether this credential may see them. Neither stands in for the other, and governance:write grants no content directly — it changes what the other checks decide. See Permission scopes.

How long each kind of content is kept

The grid above answers what recorded content may be used for. A retention window answers a second question about the same seven kinds: how long is it kept at all.

Each kind can carry its own window, in days, independently of the others — transcripts for seven days while replay recordings stay for thirty is a coherent posture and a common one. A kind with no window set is kept for as long as the organization keeps that data anyway, which is the default and is what every project starts with.

Two properties are worth knowing before you set one.

A window only ever shortens. It brings deletion forward; it cannot extend how long anything is kept. The longest window you can set is 365 days, the platform storage ceiling. Your organization’s effective history window can be shorter; setting a content window never extends that entitlement or restores expired content. Values above the ceiling are refused.

Shortening a window is the one setting here you cannot undo. Widening a denied cell in the grid above brings the content back, because the content is still there and was only withheld. Widening a retention window brings nothing back. Set one deliberately, and prefer trying it on one project before applying it across an organization.

Every change is recorded — which kind, the new window, what it was before, who changed it and when — so an audit can answer "who set transcripts to one day" months later.

Editing it

You set retention windows with the API, the CLI or MCP (see below). You save the complete set of windows at once, the same way you save the grid: a kind you leave out has its window removed and goes back to the default. That is deliberate, because removing a window is how you undo a tightening, and a form that could only ever set numbers would have no way to express it.

governance:read shows the windows; governance:write changes them — the same two permissions as the grid, because this is the same control along a different axis.

What a window actually does to your data

A window that has passed does not remove the record of what happened — it removes the content from it.

For transcripts and tool arguments that means the prompt, the completion, the tool arguments and the tool results are erased from the trace, and the trace itself stays: its timing, its status, its service, its token counts and every other attribute are untouched. That is deliberate. Expiring a transcript by deleting the trace would delete the operational record you set the window to trim, and you would lose the ability to see that the call happened at all.

The same erasure reaches everywhere else that kind of content is kept, not only the trace. If a prompt was carried on an agent step, on a metric's exemplar, in an error's tags, extra or request headers, in the tags shown on the issue that error rolls up into, or in a product event's properties, the window removes it from each of those too, and each of those records likewise stays.

There is no longer an exception. A log line's attributes, the resource a log was emitted from and a metric's own labels used to sit outside the window and expire only on the organization's much longer storage schedule; they are now cleared on your window like everywhere else. The log line and the metric point themselves stay, with their message, severity, service, value and every non-content label intact, so a short window trims the content without costing you the record that it happened.

For session replay the recording IS the content, so the recording and its snapshots are removed outright.

Windows are enforced on a schedule rather than at the instant they pass, so content can survive for a few hours past its window before the next pass removes it. Once removed it is gone; there is no recovery.

Person-property windows clear expired individual values from the current profile and saved property history. Account-property windows clear expired bags and queued copies, including the values used by account reads. Work is bounded and resumes after interruption. Identity, linked identifiers and account membership remain. Fresh values are kept; old delayed updates cannot restore expired values. A saved setting is not proof that the next scheduled pass has finished.

memory_item is a declared disclosure class without stored content. Retention windows for it are refused; a setting is accepted only when its content can be expired.

Erasing one person's content now

A window is a schedule. When somebody asks you to erase what you hold about them, you do not want to wait for one.

DELETE /api/v1/projects/{projectId}/content/{class}/{subjectRef}

Subject clearing supports model_transcript and tool_arguments. subjectRef is the person's distinct_id inside this project. The JSON body requires both a reason (at most 400 bytes) and a canonical UUID operation_id. Keep the same UUID and reason when retrying the same decision.

{"reason":"Account owner requested removal","operation_id":"649ebca1-0452-45b7-aad3-29411ad0f6cd"}

The operation clears that person's class-specific attributes from subject-addressable telemetry records and preserves the surrounding records and other people's content. Anectico stores the original decision and records a tamper-evident receipt naming the caller, class, subject and result. A first operation that clears zero rows still has a receipt.

An exact retry returns the original rows_affected, already_erased and action_id; it does not clear again after durable completion. already_erased means the original operation cleared zero rows. Reusing the UUID with different scope, subject, class, requester or reason is refused. Clearing content collected after completion requires a new UUID. Pending recovery can clear content that arrives before the original operation completes; this is not a permanent collection ban.

A subject clear also makes older native product-analytics results depending on that content class unavailable across this project, including their participant pages and audience previews. Restoring identical event content does not revive the old result. A content-independent result keeps its usual read checks. Run a new query with a new execution key for a fresh measurement; new collection remains permitted by the current policy. Pending clears refuse dependent reads, and older frozen evidence without erasure revisions is unavailable. The response manifest carries opaque content_erasure_revisions; they are evidence, not an authorization token.

If receipt_missing is true, the clear completed but its receipt acknowledgement remains pending. Recovery retries the frozen receipt without repeating a completed clear. Persistent failures need operator attention. The response keeps the stable action_id so you can inspect that chain.

Session replay cannot be erased for one person this way. The recordings are selected by age across a project and there is no per-person selector, so the request is refused rather than deleting every recording in the project to be sure of covering one. Delete the individual recordings instead, or erase the person: that removes the person together with every recording made under their identifiers.

governance:write is what allows it, and it is bounded to your own organization.

The same answers over the API

GET /api/v1/content-policies
GET /api/v1/projects/{projectId}/content-policy
PUT /api/v1/projects/{projectId}/content-policy
GET /api/v1/projects/{projectId}/content-policy/retention
PUT /api/v1/projects/{projectId}/content-policy/retention
GET /api/v1/projects/{projectId}/content-policy/access-audit
DELETE /api/v1/projects/{projectId}/content/{class}/{subjectRef}

With a project-scoped API key, {projectId} must match the key's project. A conflicting path returns HTTP 403 before reading or changing any project's policy, retention, or content, even when a project_id query parameter matches the key. A refused erasure creates no operation or receipt and does not change the content-erasure revision. Organization-wide user sessions select the project from the path. A blank or whitespace-only project path returns HTTP 400 before any read or change, including when the whitespace is URL-encoded.

Both reads return every cell, denied ones included, so you can render the grid without knowing the vocabulary in advance. The PUT replaces the grid; pass the expected_version you last read to have the write refused if somebody changed it meanwhile.

The retention routes answer only the kinds that HAVE a window — a kind with none is genuinely absent rather than reported with a default number, because a number in this screen is an instruction to delete and you should never be shown one you did not choose. The PUT replaces the whole set. Full request and response shapes are in the REST API reference.

The access-audit route lists what the policy REFUSED, newest first, and takes optional content_class, sink, principal_id, since, until and limit filters. An omitted filter means every value rather than the unset one, so a bare call returns the whole project. Remember what the section above says about it: an empty page means nothing was withheld, never that nothing was read.

The same actions from the CLI and MCP

The CLI acts on the active project (--project or the selected one):

anectico content-policy get                       # the grid and its version
anectico content-policy set --expected-version 4 --file policy.json --yes
anectico content-policy retention get
anectico content-policy retention set --file retention.json --yes
anectico content-policy access-audit --sink export
anectico content-policy erase person_properties user-42 \
  --reason "erasure request #881" --operation-id "$(uuidgen | tr A-Z a-z)" --yes

set and retention set replace the whole set, exactly as the PUT routes do. erase needs a reason and an operation id you generate; keep the id if you may need to retry, because reusing it returns the original erasure instead of erasing again.

An MCP agent reads through list_read_actions (list_content_policies, get_content_policy, get_content_retention, list_content_access_audit) and changes through list_write_actions (set_content_policy, set_content_retention, delete_content). Every change previews first and applies with the returned confirm_token. set_content_policy needs the expected_version you read, and the set_content_retention preview names every window that would get shorter. All of them need the same admin permissions as the Console tab.

Review the server preview

All native CLI changes on this page use the same server preview as MCP. The first call changes nothing. Read complete before and proposed values, the required permissions and consequences; the policy includes every implicit deny. Proposed audit authors and timestamps are marked as assigned by the server when the change is committed. Repeat identical arguments with --confirm-token <token> after approval. --yes acknowledges permanence and does not apply a write without a preview token. A missing custom retention window means the normal platform history window, not unlimited history. It creates no separate property purge instruction; set a custom property window to expire those values.

A person_properties subject clear resolves the canonical person from the exact identifier and clears current and saved property values through that operation's snapshot. It preserves identity, linked identifiers and memberships, and permits future updates. It does not erase telemetry or invalidate unrelated analytics results. Transcript and tool clears also invalidate older dependent analytics evidence across the project. The preview states this effect, including results about other people, and excludes downloaded copies, external destinations and backups.

App-view sharing controls

Privacy → Content policy decides Aggregate result → App-view sharing for the selected project. Missing, unknown or denied consent refuses sharing; an ordinary read permission does not permit it. Only the governed policy write may enable it. A policy version change requires a new review for pending grant creation and ends previously admitted token authority. Review and revoke individual grants on Agents and keys. A parent-key revoke stops all descendants. Already displayed or copied numbers cannot be recalled. See the browser aggregate recipe for exact scopes, origins and limits.

Public static pages and copies

The aggregate-sharing app-view policy also controls publishable static pages. This is sharing outside your organization. Anyone copying the published credential can read that exact aggregate, even by forging Origin. Denial, revocation or erasure ends future disclosure, including matching validators. Already displayed or downloaded content cannot be reclaimed; your own retention and disposal policy covers external page, cache and log copies.