Policy version: v1. Mike Khristo approved these terms while acting as the Product, Security, and Legal approver for closed implementation. That approval does not authorize source admission.

These terms describe the source-data boundaries that will apply if Layers opens source-based agent onboarding. Source admission is currently closed. Layers will not accept source under this policy until the required security, processor, storage, cleanup, and public-policy checks are complete.

1. Before you approve source data

If source admission opens, the Layers collector will run locally and read-only. Before approval, no repository body, source excerpt, free-form repository value, or digest payload leaves your source environment or enters a Layers service, model, model provider, or the host agent's model through the Layers flow. Layers also makes no website or store lookup derived from your repository.

The collector will enforce path and secret exclusions, content and byte limits, binary and generated-output exclusions, truncation, hashing, and the pre-approval output allowlist. Before approval, the host will see only sanitized structural facts, typed public targets, and bounded consent-path items. Filenames will be treated as untrusted data, normalized, escaped, length-bounded, and represented by stable path IDs. You will be able to exclude a path or public target before approving it.

If source admission opens, a public GitHub URL may then authorize the same-session local bootstrap to inspect a pinned public revision. It will fetch only policy-eligible blobs into a process-private, memory-only workspace capped at 4 MiB. It will not clone or archive the repository, write a repository body to a file, execute repository code, or send a fetched Git blob, full file, or unapproved repository content to Layers. The preparation will expire after 15 minutes. Private GitHub access will not be requested or inferred.

2. Your approval

If source admission opens, before any approved source payload or source-derived public lookup leaves the source environment, Layers will show an immutable receipt. It will identify policy and schema versions, the selected product and source identity, included path IDs and byte bounds, structured fact categories, public targets, exclusions, processors and public services, retention terms, and source and consent hashes. Approval will apply only to that exact scope. A change to the selected product, root, path set, transmitted content, category, exclusion, byte count, or public target will require a new receipt and affirmative approval.

A follow-up read may reuse an approved scope. Anything outside that scope will require another receipt and approval. Retries may reuse the same accepted evidence identity but cannot widen its scope. The server will independently verify the policy, schema, scope, and evidence hashes before accepting data.

3. Data Layers may receive

After approval, Layers may receive these bounded product facts:

the selected product root and evidence kind;
product display-name candidates and platform identifiers;
manifest, framework, package-manager, public dependency package, and declared version-range identifiers;
bundle, package, numeric store, and public Layers App IDs. A public Layers App ID is app_ followed by exactly 16 or 24 lowercase alphanumeric characters;
typed website and store candidates;
sanitized consent-path items, exclusions, and counts;
immutable source, evidence, and consent hashes; and
the limited prose excerpts described below.

Accepted evidence never includes a full repository tree, lockfile, source-code line, grep output, image, binary, generated output, environment value, credential, or arbitrary command output. Secret paths, credentials, planted key material, binary files, generated outputs, and other policy exclusions are unrepresentable in the transmitted payload, approval record, telemetry, and model input. Exclusion records contain categories and counts, not secret values. Layers never authenticates with a credential found in source.

4. Prose excerpt limits

Layers may receive at most three product-description excerpts, with a combined limit of 8,192 UTF-8 bytes:

up to 1,024 bytes from one statically parsed, allowlisted identity-manifest description field;
up to 3,072 bytes from a top-level README.md, limited to its first H1 and the first nonempty prose paragraph under the first following H2, stopping before the next H2; and
up to 4,096 bytes from one top-level handoff brief named exactlyPRODUCT_BRIEF.md, PRODUCT.md,HANDOFF.md, or<selected-product-slug>-Design-Brief.md. For the last form, the normalized filename prefix must exactly equal the already selected, structurally derived product display name under the approvedselectedProductSlug comparison. Its first H1 and first nonempty prose paragraph under the first qualifying H2 are eligible. The H2 is normalized with Unicode NFC, whitespace trimming and collapsing, Unicode case folding, and removal of at most one leading one- or two-digit ASCII decimal ordinal followed by . or ) and whitespace. The result must equal exactly overview orproduct summary.

If no selector matches, the excerpt is omitted. If credential detection matches anywhere in an allowed file, every excerpt from that file is omitted. Code, lockfiles, arbitrary follow-up files, and user-supplied shell output are not excerpt sources.

5. Processors and public services

Approved structured facts may enter the Layers API and Supabase. Approved prose excerpts may pass through the Layers API into a dedicated, application-encrypted transient object store in Google Cloud and to a dedicated Vertex AI analysis client. The transient store must have versioning, soft deletion, retention locks, and separate backups disabled. Prose excerpts do not enter a backup-enabled Supabase table.

Google Cloud Logging may receive only source-free operational metadata limited to trial and evidence pseudonymous IDs, policy and schema versions, category counts, byte counts, timestamps, durations, state transitions, support codes, and bounded error classes. It receives no repository path, excerpt, public target, receipt body, or credential. Firecrawl may retrieve an approved public website or store page. Apple App Store and Google Play are public lookup services. GitHub is the public remote-repository service. Public lookups contact only a target shown in an approved receipt and use exact identifiers, never a fuzzy name match.

Repository bodies and raw excerpts do not enter E2B, the Gemini Developer API, OpenAI, Anthropic, Mastra Platform, PostHog, Sentry, Cloud Logging, Elle, Firecrawl, Apple, Google Play, a GitHub model service, or the host agent's model through the Layers flow. After approval, bounded normalized facts and grounded playback may enter Elle as product output. A public GitHub fetch uses no integration or user credential.

6. No training or secondary use

Layers does not use repository data, prose excerpts, or derived facts for model training, fine-tuning, human labeling, evaluation corpora, product analytics, or advertising. A provider path cannot be enabled unless its terms and approved configuration support this boundary.

Named, owner-authorized fixtures may be used only for the final release verification fleet or closed pre-admission policy probes. Both proof paths prohibit raw excerpts, repository bodies, unsanitized paths, and credentials. Final-fleet audit bundles may remain for at most 30 days and must be deleted before their verification cell may pass. A pre-admission probe retains only its signed typed primary artifact, signed cleanup artifact, and source-policy manifest reference under the shorter applicable lifecycle. It is not an acceptance cell, creates no final-fleet projection, and cannot be reused by the final fleet.

7. Temporary workspace

If source admission opens, Layers will create an isolated, trial-scoped workspace only to analyze approved evidence, build a preview, and let you claim or resume it. Depending on the path, it may include an upload grant, upload-intent lease, evidence and public-validation records, jobs, an anonymous authentication user, organization and membership, and, for a normal new-product preview, a temporary project, SDK record, entitlement, credits, media, and preview assets. Existing-App-ID previews will create no duplicate project before authorization. Nothing will be exposed to another account before an authorized claim.

The browser flow may create or sign in to your normal Layers account. If source admission opens, that account will remain user-owned even if a product claim is denied, and the deletion rights in section 9 must be available.

8. Retention and deletion

If source admission opens, these schedules and triggers will apply:

Upload grants and public-GitHub preparation expire after 15 minutes.
A preview-ready, unclaimed evidence workspace remains claimable for 7 days. Failed or abandoned work that never becomes preview-ready is due for deletion within 1 hour of its cleanup trigger.
Raw prose excerpts are deleted at the earliest of successful analysis, preview readiness, claim, or 24 hours after acceptance. Active-system deletion completes within 1 hour of that trigger. Preview-ready and claimed records contain no raw prose excerpts.
Approved structured facts, hashes, and provenance may remain for the claimed project's lifetime. They are deleted from active systems within 24 hours after source-data-only, project, or account deletion. Backup expiry is 30 days after its required verification. A content-free compliance receipt may remain for 12 months.
Raw public-page responses are deleted within 24 hours. Normalized public facts and provenance may remain for the project lifetime and follow the same deletion periods as structured facts. Public images explicitly selected for the preview follow project-lifetime deletion rules. The Firecrawl path must have vendor caching disabled and approved zero-retention mode proven by account readback. Otherwise Layers uses a guarded Layers fetch or keeps that lookup path closed.
Source-free operational events may remain for 30 days. Aggregate, content-free counters may remain for 12 months.

Rejection, cancellation, expiry, failed or abandoned creation, terminal analysis failure before preview readiness, and explicit source revocation trigger the applicable cleanup. A failed claim attempt does not delete, replace, burn, or extend an accepted workspace. Successful analysis or claim triggers raw-excerpt deletion.

9. Your source-data rights

Once the flow is available, a signed-in view and API response will show the retained structured categories, normalized values, provenance, receipt and policy identity, retention deadlines, and excerpt purge state. You will be able to delete source-derived data without deleting the project, and may also delete the project or account. Source revocation will cancel in-flight analysis, block future follow-up reads, and delete source-derived previews and generated onboarding assets. Before claim, the trial capability will provide a bounded cancel and delete operation. Deletion will return a receipt without returning source content.

10. Cleanup and admission safeguards

If source admission opens, the expiry reaper must run at least every 5 minutes, and required cleanup must finish within 1 hour of its trigger. Layers must record resources by trial and evidence identity and produce an identity-scoped, idempotent cleanup receipt. An unexplained resource fails verification. Admission closes on the first failed sweep or when cleanup remains pending for 15 minutes, while existing status, claim, and cleanup paths remain available.

Source admission remains closed until the approved processor and storage configuration, deletion behavior, access controls, user rights, cleanup, and signed policy proofs are verified and this page is independently read back by its deployed content hash. Publishing these terms does not open source admission or advertise the source flow as available.

11. Contact

Questions about these terms can be sent tohello@layers.com.