1. Scope, draft status and privacy roles
This proposed notice describes how personal information may be handled when BBA operates the features covered by it. It applies to BBA-controlled account and marketplace activity, private manufacturer workspaces, support channels, community forums and supported agent interactions. Actual processing depends on which features are enabled and used. The published development preview uses sample data and does not establish that production collection, account services or live support are active.
BDT Apex Engineering, LLC, a Wyoming limited liability company, is the identified BBA operator. Contact support@bdtapex.net for BBA privacy questions or requests. A confirmed business mailing address must be added before adoption. For account administration, platform security and its own business obligations, the operator may determine the purposes and means of processing. For personal information a business places in its private operational workspace, BBA may instead act on that business's documented instructions under a data-processing agreement. The actual agreement and applicable law determine the roles; an account label alone does not.
A marketplace seller, buyer, payment provider or other independent recipient may determine its own processing after an authorized disclosure. Its own notice may apply to that activity. BBA's notice does not authorize that recipient to reuse private drawings, customer details or support content for unrelated purposes.
2. Sources of information
Information can come from you, members of your organization, an authorized agent acting for an account, transaction counterparties, support participants and service providers operating an enabled integration. BBA may also receive records generated by your use of the service, such as request times, action receipts, permission decisions and technical connection information.
When an organization supplies information about its employees, customers or other people, it must have a lawful basis and provide the notices required for its use. An agent must not gather or submit information merely because it can reach a page. It must stay within the user's instructions, current permissions and the intended purpose of the task.
3. Information categories and their purposes
The following categories describe relevant product data. They are conditional on the actual feature and account activity. Sensitive documents should remain in the appropriate protected workflow rather than being copied into public posts, URLs or general support messages.
BBA must collect only information reasonably needed for a disclosed purpose. The production inventory must identify which categories are actually collected, which are mandatory, the lawful basis where required and the recipient categories before the final notice is adopted.
- Account and contact information. Names, email addresses, account identifiers, business contact details, role and verification status support registration, communication, membership administration and recovery.
- Organization and permission information. Workspace identifiers, memberships, roles, invitations, policy limits and approval history support tenant isolation and the authority to view or change records.
- Authentication and security information. Password verifiers, authentication challenges, session information, security-key public credential information, recovery evidence and risk signals support account protection. Do not send passwords, recovery codes or private security-key material to a forum or support agent.
- Marketplace and transaction information. Listings, supplier contacts, RFQs, quotes, order terms, shipping contacts, origin evidence, payment references, disputes and related communications support discovery, purchasing, fulfillment and recordkeeping.
- Private operational information. Customer or employee identifiers appearing in jobs, inspection records, accounting entries, schedules, inventory events, machine events and attached documents support the business's authorized operations.
- Community and support information. Published profile details, topic and reply content, chat messages, reports, moderation records and relevant troubleshooting context support guidance, case handling and community safety.
- Technical and usage information. IP address, browser/device information, request timestamps, errors, relevant service events and preference settings may support delivery, security, diagnostics and usability. The final inventory must distinguish essential telemetry from optional analytics.
- Agent-related information. The connected account, delegation evidence where supported, declared authorship, permitted task context, requests and results may support attribution, auditing and recovery. A self-declared agent label is not verified identity.
4. Payment and verification information
An enabled payment or verification flow may send necessary information directly to the identified provider and return a limited status or reference to BBA. The final notice must identify the active arrangements, their data flows and the respective privacy roles. A payment integration in source code is not proof that a particular processor is live or that all card or identity information bypasses BBA.
Use the designated secure flow for financial account details, tax forms and identity evidence when requested. Do not include full card numbers, bank access credentials or identification documents in public discussions or ordinary chat messages. Transaction and dispute records may require retention even after an account closes, subject to applicable law and a documented retention purpose.
5. How information is used
The operator may use relevant information to provide an enabled feature, administer accounts and memberships, complete an authorized transaction, maintain operational records, answer support requests, deliver service notices, investigate abuse and meet applicable legal obligations. Each use must be tied to a real feature or obligation and limited to the information it reasonably needs.
Security and integrity uses can include checking permission changes, detecting unusual requests, preventing duplicate commands, investigating fraud and preserving the history needed to explain a commercial or operational event. Information from one company's private workspace must not become another company's public evidence or private prompt merely because both use the platform.
Optional marketing, advertising, unrelated profiling, benchmarking and AI-model improvement require a separate assessment and any notice, permission or opt-out required by law and the relevant contract. A broad statement that information is used to improve the service is not sufficient to authorize every such use.
6. Processing grounds where applicable
Where a law requires a processing basis, the operator must identify the basis for the specific activity. Depending on the facts, it may include performing an agreement with you, a legal obligation, a documented legitimate interest balanced against individual rights, or valid consent. An organization's processor agreement and instructions may govern processing carried out for its private workspace.
Consent must be specific to the activity for which it is requested and may be withdrawn for future consent-based processing through the applicable control or confirmed privacy channel. Withdrawal does not automatically reverse a completed transaction or eliminate a separate legal retention obligation. The operator must not treat acceptance of general terms as universal consent to optional processing.
7. Private workspace data and intentional disclosure
Private workspaces can contain proprietary business information as well as personal information. Access should follow current membership, role and record-level permissions. A private record, document, support conversation or agent context is not public merely because it is stored in BBA.
Publishing a listing, posting to a public forum, sharing an RFQ or submitting dispute evidence can disclose selected content to a new audience. The user must be able to review the intended audience and relevant material before authorizing that disclosure. Avoid including personal information or confidential technical content that the recipient does not need. A later access change may not remove copies already lawfully received by a counterparty or public reader.
For privacy requests involving an organization's records, BBA may need to refer the request to that organization or coordinate under its processing agreement. This does not justify ignoring a request for information BBA controls independently or disclosing the organization's records to an unverified requester.
8. Public profiles and forum content
A forum topic or reply submitted with a public audience can expose its body, chosen display name, publication time and other clearly disclosed profile information. Other participants may quote, copy or share that content. Search engines or external services may retain material they can lawfully access. A private development Site may impose an additional hosting access gate; the final production forum visibility must be stated clearly.
Review public content before submitting it. Do not post account credentials, recovery codes, personal contact details you lack permission to share, confidential customer information or restricted manufacturing files. Public posting requires the account connection and disclosure confirmation provided by the service. An agent's permission to read a private record does not imply permission to publish it.
Reports and moderation records can contain personal information. They should be available only to authorized participants and moderation personnel, with an appropriate audit trail. An appeal or report may require relevant context to be reviewed, but it should not republish the reported material unnecessarily.
9. Private live chat and support context
An account-connected support conversation may contain your account identifier, message content, timestamps, topic, relevant service state and any context you intentionally provide. Its private audience is different from a public forum audience. The operating support process must identify who can view a conversation and whether an AI system is used to answer or analyze it.
A typing indicator, presence signal, transcript, recording or automated summary is a separate processing choice. Only the features actually disclosed and implemented should collect that information. This notice does not claim that BBA records calls, captures unsubmitted keystrokes or has human personnel continuously monitoring a chat window.
Support may need enough information to investigate an issue, but account verification and permissions still apply. Share a record link or minimal diagnostic detail when that is sufficient. Do not send secrets or entire private datasets to obtain routine guidance. Escalating a conversation should preserve its stated confidentiality and authorized audience.
10. AI systems and agent access
An authorized agent can process information visible to its connected account within the permitted task. Any external agent service may have its own data-handling terms. Users and organizations should review those terms before granting access to private records. BBA must distinguish verified delegation from a participant's self-reported authorship label.
If BBA enables an AI guidance or support provider, the relevant notice must identify the information sent, the purpose, recipient, retention and model-improvement treatment, material cross-border processing and applicable controls before private information is sent. The present development evidence does not establish an active provider or its complete contractual data-use settings.
Neither the content license nor this draft grants blanket permission to use private workspace data, chat transcripts or controlled technical content to train a shared model or disclose it across companies. The final policy and applicable agreements must resolve any proposed training, evaluation or benchmarking use explicitly. General navigation files supply task hints and create no additional access authority.
11. Recipients and disclosure purposes
Relevant recipients may include authorized members of your workspace, the counterparties you choose for a transaction, support or moderation personnel with a legitimate role, and providers necessary for the enabled service. Provider categories may include hosting, database and storage, payment processing, communications, security, delivery or disclosed AI services. The actual provider list, processing locations and contractual responsibilities remain to be confirmed.
BBA may need to disclose information when a valid legal obligation requires it or when a lawful and proportionate disclosure is necessary to protect rights, investigate fraud or address a serious security or safety issue. The request must be assessed rather than treated as unrestricted access. Notice to affected people should be provided when appropriate and legally permitted.
A merger, financing, reorganization or sale of business assets may require a limited, protected disclosure. Any transfer must remain subject to applicable privacy law, contractual confidentiality and appropriate notice. Such a transaction does not automatically permit unrelated uses of private manufacturing or support information.
13. Advertising, sale/sharing and preference signals
Whether a data flow counts as a sale, sharing for cross-context behavioral advertising or targeted advertising depends on actual practices and the applicable law. The verified production inventory is not yet complete. This draft therefore makes no categorical no-sale, no-sharing or no-targeted-advertising representation.
Before enabling a covered practice, the operator must provide the required notice, opt-out route, consent where required and any legally mandated treatment of recognized preference signals, including Global Privacy Control where applicable. A control should be described as operational only after its effect has been verified. A contractual statement alone does not implement an opt-out.
For California and other U.S. states with applicable privacy laws, the final notice must identify the relevant categories, purposes, recipient categories, retention disclosures and available rights for the covered processing. Applicability, exemptions and any required prior-period disclosures must be assessed from the real business and data inventory rather than assumed from the U.S. focus of the marketplace.
14. Retention, correction and deletion
Information should be kept for the period reasonably needed for its stated purpose, a valid business or legal obligation and the applicable agreement. Relevant factors include an active account or transaction, tax and financial recordkeeping, product or quality traceability, unresolved disputes, security investigations, legal holds and the ability to prevent unsafe duplicate commands. Those factors do not authorize indefinite retention of every record.
Account and preference information, public community content, private support conversations, operational records, technical logs and backups can have different retention needs. The operator must approve concrete schedules and a tested deletion or de-identification process before the final policy is adopted. This draft does not promise a fixed retention period or immediate deletion from every backup.
An immutable business event or retained action receipt may need a correction, restricted view or minimal retained identifier rather than destructive rewriting. The operator must assess personal information in such records and preserve only what it can lawfully justify. Closing an account, withdrawing a public post, ending workspace access and making a privacy deletion request are different processes. Where a request cannot be completed in full, the response should explain the applicable reason and available review route.
15. Security and incident handling
BBA's product requirements include authorization, tenant separation, protected session handling, validated requests, controlled file access, audit evidence and deterministic approval for money, inventory and physical controls. The effective security program must verify the relevant deployment, access practices, encryption configuration, provider controls and recovery procedures. Source code or a local test does not establish a certification or guarantee that an environment is secure.
No service can promise absolute security. Use supported authentication protections, restrict memberships and avoid sending secrets through public or unnecessary channels. An incident response must assess the actual information and systems affected and provide notices required by applicable law and contract. This draft sets no invented incident-notification deadline or guarantee of uninterrupted access.
16. Individual privacy rights and choices
Depending on the applicable law and your relationship to the information, you may have rights to access, correct, obtain a copy of, delete, restrict or object to processing, withdraw consent, opt out of specified processing, limit certain sensitive-information uses or appeal a decision on a request. Rights have different scopes and lawful exceptions. The adopted notice must identify the supported request channels and the rights relevant to the actual service.
A request should provide enough information to locate the relevant account and explain the right being exercised. BBA may verify identity and, for an authorized representative, the representative's authority using proportionate information. It should not require unnecessary sensitive identification. A verified requester is still not entitled to another person's private information or another company's confidential records.
Respond within the deadline required by the applicable law, with any permitted extension and its explanation. If a request is denied or partly fulfilled, explain the basis and available appeal or regulator complaint route where required. Exercising a right must not lead to unlawful discrimination. Necessary security checks and the practical consequences of deleting data required for a service should be explained honestly.
17. Profiling and consequential decisions
BBA may use rules or automated assistance for routing, validation, fraud detection, search or operational planning when that feature is enabled and disclosed. A recommendation, search ranking or support answer should be distinguished from a decision that changes account access, a financial obligation, a production event or another legally significant outcome.
If a deployment uses personal information for a legally regulated consequential automated decision, the operator must assess the applicable notice, explanation, human review, objection or opt-out requirements and implement them. This draft does not claim that every automated decision is legally exempt or that an unimplemented review control is available. Account and physical-control authority must remain under the applicable deterministic policy.
18. Processing locations and international access
BBA focuses on U.S. technology manufacturing. That focus does not establish that all hosting, support, providers or agent services operate only in the United States. Actual processing locations, remote access, eligible markets and any required transfer safeguards must be documented before a location or residency promise is made.
Where international privacy law applies, the operator must identify the appropriate legal mechanism and any additional assessment or safeguards for the actual transfer. Merely visiting a site or accepting general terms does not provide universal consent to every transfer. Mandatory individual rights continue to apply where the law provides them.
19. Children and other people's information
The proposed service is intended for adults and authorized business users. The operator must confirm the final eligibility rule and implement any age-related controls needed for that audience. Do not create an account for a child or submit a child's personal information through marketplace or support content without a lawful, expressly supported reason.
If BBA learns of information collected in violation of an applicable children's privacy requirement or its adopted eligibility rule, it must assess the information, stop unauthorized use and take the action the law requires. This draft does not claim that an age gate, parental-consent process or children's-data workflow is already operational.
20. Contact, complaints and policy changes
Send BBA privacy questions or requests to BDT Apex Engineering, LLC at support@bdtapex.net. The operator's business mailing address is still required before adoption. General forum posts are unsuitable for a request containing identity evidence or confidential information. Ask for a protected verification method when the request needs such evidence; do not attach credentials or unnecessary sensitive records to an initial message.
The operator must identify a version and effective date for each adopted notice and explain material changes through an appropriate notice method. Changes should apply prospectively unless a lawful basis and proper notice support another treatment. New processing that requires additional consent or another specific choice cannot be authorized solely by revising this text. Keep a record of the notice applicable to the activity in question.