1. Scope and current Beta boundary
This Notice applies to a user-directed or vendor-authorized evaluation, including its target configuration, test inputs, result records, evidence manifest, review, and publication. It supplements the Privacy Policy, Acceptable Use Policy, Vendor Participation Terms, and the active evaluation methodology.
No evaluation is considered available merely because a route, schema, worker contract, or status response exists. Folkbench will publish the activation boundary and any changed processing before enabling a materially different production run.
Current product rules distinguish platform health probes from user-directed evaluation: automated platform checks are limited to connectivity, while non-connectivity checks require an explicit one-time user request. Availability still depends on the published status and configuration; this Notice does not itself authorize a run.
2. Roles and instructions
Havenbyte LLC is the controller for information it processes to operate Folkbench, protect the service, maintain audit records, and publish reviewed directory facts. A vendor or organization remains responsible for the personal data and authorization it supplies.
If a signed data-processing agreement makes Havenbyte LLC a processor for a vendor-controlled dataset, that agreement controls the documented instructions, data categories, data-subject categories, security measures, subprocessors, transfers, deletion, and audit assistance. Do not submit third-party personal data without that documented arrangement.
3. Authorization and target safety
The person starting a run must have authority to test the endpoint, account, tenant, model, data, and credentials involved. Vendors must expressly authorize each target and define allowed protocols, limits, budget, test window, and stop conditions.
Folkbench applies server-side URL, DNS, port, redirect, response-size, timeout, rate, and private-network controls. A target may be rejected or a run stopped when authorization or safety evidence is incomplete.
4. Data categories
- Run and attempt identifiers, authorization records, configuration, model and protocol identifiers, timestamps, status, latency, compact result facts, and review decisions.
- Synthetic prompts, bounded test inputs, responses, error categories, traces, logs, screenshots, and attachments generated or collected during an authorized run.
- Account, organization, vendor representative, support, security, and correction information needed to administer the run and protect the service.
- Secret references and scoped credential metadata. Raw API keys, passwords, session cookies, payment credentials, and unrelated customer content are not required inputs and must not be submitted.
5. Input minimization and prohibited content
Use synthetic or redacted inputs whenever possible. Do not include names, contact details, health information, financial information, government identifiers, children’s data, confidential customer content, or special-category data in a test prompt unless a separate written assessment and agreement expressly permits it.
Folkbench does not train a model on submitted evidence, sell it, or publish raw request and response content. A result can be rejected, quarantined, or deleted when it contains unnecessary personal data, secrets, malware, or material outside the authorized scope.
6. Processing and evidence flow
A future run will first receive a database run and attempt identity. Process evidence will be streamed to a private quarantine object, checked for size, hash, type, and redaction status, and only then linked to a database manifest in the same state transition. Public pages will read reviewed, sanitized, versioned facts rather than raw evidence.
A failed upload or manifest write must not produce a completed result. A successfully uploaded object without a manifest is an orphan candidate for controlled reconciliation; it is not a public artifact and is not deleted solely because one request failed.
7. Purposes of processing
Processing is limited to authorization and safety checks, executing the approved evaluation, producing compact results, reviewing evidence, correcting or withdrawing a publication, preventing abuse, maintaining security and audit records, supporting the account, and meeting legal obligations.
Folkbench will not use evaluation evidence for unrelated advertising, sell it, or combine it with unrelated user profiling. Any new purpose requiring materially different processing will be disclosed before activation.
8. Retention and deletion
Production collection of raw evaluation artifacts is not active at the effective date. Before activation, Folkbench must publish and enforce an artifact-specific schedule, lifecycle rule, legal-hold rule, and joint database/object-storage recovery procedure.
The proposed Beta baseline is quarantine up to 24 hours, raw process evidence up to 90 days after finalization, run and manifest metadata up to 24 months, and published facts and audit history for as long as needed to explain a public record and meet legal obligations. A signed agreement or legal hold may set a different period.
When a deletion request is approved, Folkbench will remove or anonymize data within the applicable scope where it is technically and legally possible. Published facts, security records, and audit trails may be retained when necessary to preserve integrity, prevent fraud, or comply with law.
9. Service providers and subprocessors
A future run may use server-side compute, PostgreSQL, private S3-compatible object storage, identity, email, monitoring, and security providers. Each receives only the data needed for its documented function and may not use it for its own unrelated purposes.
A vendor-controlled processing arrangement will identify the approved subprocessor classes and any notice or objection mechanism. Folkbench will not expose bucket names, object keys, presigned URLs, raw headers, internal addresses, or credentials on public pages.
10. International transfers
Folkbench and approved service providers may process information in the United States and other locations. Where a transfer law applies, Havenbyte LLC will use an applicable adequacy decision, standard contractual clauses, or another lawful mechanism with supplementary safeguards. The actual provider location and mechanism will be recorded before a production run is enabled.
11. Security and incidents
Controls include server-only credentials, least-privilege access, encrypted transport, private quarantine and final objects, controlled object keys, bounded streaming, checksums, redaction, request and run identifiers, audit trails, and publication gates. Repository code, a client configuration check, or one successful request is not evidence that a production control is complete.
Report a suspected exposure or unauthorized run through the contact page with a safe case identifier. Folkbench will investigate, contain, preserve evidence, and notify affected parties or authorities when required by applicable law or agreement.
12. Vendor and user responsibilities
You must provide accurate authorization, use scoped and revocable test credentials, observe the approved test window and limits, minimize inputs, identify confidential material, and promptly report a target change, withdrawal, incident, or correction. You must not treat a sample result as a guarantee, certification, or complete privacy or security audit.
13. Requests and contact
Questions, access or deletion requests, objections, correction requests, and vendor instructions can be submitted through the Folkbench contact page. State the relevant run, attempt, organization, or account identifier when safe; do not send credentials or raw private evidence in an initial message.
14. Relationship and changes
The Privacy Policy, Terms of Service, Acceptable Use Policy, Vendor Participation Terms, active methodology, and any signed data-processing agreement apply together. A signed agreement controls if it expressly conflicts with this online Notice.
Folkbench will update this Notice before materially changing the types of test data, roles, providers, locations, retention, or publication processing. The effective date above records the current version.