Transparency notes stay visible. Legal claims stay narrower than the implementation.
This page describes the public compliance posture for selfx.dev v1: where AI use is
disclosed, how intake data is handled, and what is intentionally not being claimed. The
aim is to make the operating boundaries legible before a prospect submits a workflow.
AI-use disclosure
Automation is described as part of the workflow, not hidden behind vague language.
The public site should not imply invisible automation or autonomous decisioning. When a
delivery includes AI-assisted workflow components, the presence of those components is
disclosed directly and framed as part of a bounded operator workflow.
AI-use disclosure: Relevant pages should state clearly when the delivery involves AI-assisted workflow components rather than implying invisible automation.
Article 50 tracking note: Copy should state that Article 50 transparency and technical-marking requirements are tracked and updated without claiming blanket compliance ahead of the final implementation details.
Hosting and privacy posture
Data capture stays narrow and operationally justified.
v1 captures structured intake data for owner review, routing, and follow-up only. The
public posture is EU-conscious and limited: a Cloudflare-hosted site, bounded intake
fields, and no broad claim that every downstream client use case is covered by this page.
EU-conscious hosting and privacy posture: The public site, intake flow, and deployment posture should describe EU-conscious handling, limited data capture, and the owner-locked Cloudflare delivery stack.
Manual review before automation creep: Structured submissions are reviewed by the owner, and routing remains deterministic rather than open-ended automated decisioning.
Article 50 posture
Transparency obligations are tracked as part of implementation, not marketed as settled.
The current statement is intentionally modest. Article 50 transparency and technical
marking requirements are tracked and reflected in copy and delivery notes where relevant,
but the site does not present that tracking work as a blanket legal conclusion.
This is a tracking note for v1 and should be read alongside the scope and intake rules.
Proof limits
What this page does not claim matters as much as what it does.
No blanket AI Act claim: The site must not claim that the service is 'AI Act compliant' as a general marketing statement.
Proof stays honest: Compliance language should be explicit about boundaries, documentation posture, and the limits of what is being promised in v1.
The public promise is a bounded build-and-handover service with explicit review
boundaries. It is not a certification, legal opinion, or generalized "AI Act compliant"
marketing claim.
Intake and routing alignment
The compliance posture matches the same deterministic routing used elsewhere.
The intake flow is structured to support a manual owner review process, not open-ended
automated eligibility scoring. Public fit language therefore stays synchronized with the
routing outcomes shown on the scope page.
Decline: Any closed disqualifier or Annex III creep guard is triggered.
Tier 2: The request stays within the internal ops, support, content, or founder-tooling lane and fits the primary fixed-scope offer.
Tier 3 with legal review: The request is otherwise viable but needs a higher-complexity documentation pack or separate legal/compliance review before quoting.
Decline boundaries
Higher-risk categories are screened out before proposal work starts.
Some requests are declined outright so the public offer does not drift into higher-risk
decisioning categories or Annex III creep through seemingly operational briefs.
Hiring: Requests involving hiring or candidate decision workflows are declined.
Credit or scoring: Requests involving credit, scoring, or trade-credit decisioning are declined.
Biometrics: Requests involving biometric identification, categorization, or related systems are declined.
Law enforcement: Requests involving law-enforcement use cases are declined.
Employment decision influence: Decline outputs influencing employment, performance, retention, or compensation decisions about workers, contractors, or candidates.
Access or refund gating: Decline outputs gating user access, refunds, or account status without a human reviewer.
Credit or payment-term classification: Decline outputs classifying customers, leads, or counterparties for credit, payment terms, or trade-credit.
DSA-platform moderation pipelines: Decline moderation or labeling pipelines for end-user content where the client is a DSA platform.
Next step
Review scope boundaries first, then use intake when the workflow still fits.
This page is a boundary note, not a substitute for the public scope rules. Prospects who
remain in-bounds should use the structured intake so the owner can review the request
against the same rubric described here.