Raw-byte preservation
Whether the exact original bytes must be retained before decoding, normalization, sanitization, re-encoding, or canonical export.
PRESERVE · VALIDATE · COMPARE · CONSTRAIN
Build policies for the representation you actually handle.
A password, source file, web page, RAG chunk, media asset, and supply-chain attestation should not share one silent normalization or trust policy. Select the relevant contexts and keep every decision explicit.
Quick answer
What does the Representation Policy Builder produce?
It generates a deterministic, profile-specific representation policy, control checklist, and test plan while keeping preservation, validation, Unicode, container, metadata, provenance, capability, confirmation, output, evidence, and external-verification decisions separate. It never substitutes one universal “secure” preset for context-specific engineering judgment.
- Profiles
- 14 allowlisted contexts from prose and passwords through RAG, agent tools, supply chains, and provenance media.
- Policy decisions
- 15 independent controls with Required, Recommended, Context-dependent, Prohibited, or Externally verified status.
- Output
- Deterministic HTML, Markdown, JSON, control checklist, test plan, conflicts, resource routes, and exact external-verification requirements.
Bounded request-local builder
Select contexts that must coexist in the same system.
Choose no more than 5 profiles. Selecting more than one is useful because the resulting conflict record exposes where one universal rule would be destructive or misleading.
Fifteen separate decisions
Never hide policy disagreements inside a single “sanitize” switch.
Each decision is rendered independently for every selected profile. Status labels describe intended treatment, not implementation evidence.
Media-type and encoding validation
How declared type, extension, magic bytes, character encoding, syntax, and structural boundaries are checked before processing.
Unicode normalization policy
Whether normalization is absent, diagnostic only, comparison-only, or part of a documented storage or protocol profile.
Identifier restrictions and confusables
Whether identifier-specific script, character, bidi, skeleton, and collision rules apply to this representation.
Container inspection
Whether nested parts, object graphs, archive entries, MIME parts, chunks, relationships, revisions, or embedded resources must be inventoried inertly.
Representation comparison
Which source, structural, rendered, semantic, extracted, tokenized, or behavioral planes must be compared before a conclusion or action.
Active-content isolation
How scripts, macros, actions, remote references, forms, links, tools, and other executable or state-changing features are blocked or sandboxed.
Metadata preservation or removal
Which metadata fields are preserved as evidence, exposed to users, excluded from model input, or removed from a separately generated derivative.
Provenance labelling
How every selected field, transformation, fixture, parser, and output is linked to its source and processing history.
Model-input construction
How untrusted representations are converted into a newly constructed, typed, provenance-labelled model input instead of raw concatenation.
Capability boundaries
Which read, write, network, tool, credential, memory, or execution capabilities are available to the component consuming the representation.
Human confirmation
Which state-changing, external, financial, destructive, publishing, scheduling, or identity-sensitive actions require an explicit transaction preview and authorized approval.
Output validation
How generated text, links, structured data, files, tool parameters, and UI output are checked before rendering, sharing, or execution.
Logging and evidence retention
Which source identities, transformations, parser versions, policy decisions, results, and exceptions must be retained—and which sensitive values must never be logged.
External verification requirements
Which conclusions require an exact browser, parser, model, cryptographic service, DNS authority, registry, trust list, organizational owner, or legal/privacy authority.
Required
The profile should implement this control as a default condition before the representation is trusted or acted upon.
Recommended
The control normally improves resilience, reviewability, or evidence quality, but the exact implementation remains context-dependent.
Context-dependent
The control may be appropriate only when the application, language, protocol, receiver, or authority explicitly requires it.
Prohibited
Applying this control in the described profile would silently destroy meaning, expose sensitive data, add an unsafe capability, or create a misleading trust claim.
Externally verified
The local policy can require and record this check, but an exact external authority or version-pinned implementation must establish the result.
Deterministic request-owned output
Your representation policy will appear here.
The initial page produces no policy and performs no automatic analysis.
No policy has been generated.
Select at least one profile above. Choose multiple profiles to reveal context conflicts.
Context conflict is useful evidence
Rules that differ must remain separate.
A conflict is not an error. It identifies a place where one global setting would silently damage meaning, privacy, safety, or trust.
No conflict record yet.
Generate a multi-profile policy to compare decision status across contexts.
Implementation record
Control checklist
Every item retains its source profile, decision, and status. Completing a checkbox in a printed copy does not establish independent assurance.
No checklist yet.
Generate a policy to create profile-specific implementation tasks.
Evidence collection
Profile-specific test plan
The test plan tells an implementation team what local evidence to collect and when a conclusion must remain unresolved pending an external authority.
No test plan yet.
Generate a policy to produce deterministic test cases.
The policy is explicit about what it cannot establish.
The builder resolves allowlisted profile rules and links them to existing evidence. It does not inspect a production system, verify a cryptographic claim, evaluate a model, contact a registry, resolve DNS, assess compliance, or decide whether a control is effective.
- The generated policy is a design and test-planning record, not a security certification, compliance determination, risk score, or proof of implementation.
- A status of Required or Recommended does not establish that the control exists or works in a production system.
- A status of Externally verified records a verification dependency; the local builder does not perform the external check.
- The builder does not inspect visitor files, call a model, resolve a domain, query a registry, validate a signature, execute content, or retain the selection after the response.
- Profile conflicts are expected. They show why a single universal normalization, canonicalization, metadata, or retention policy would be unsafe.