Here is the operational boundary around data, access, and the conversations that begin on this site.
We keep the public intake explicit, narrow, and honest about what it does—and what it does not do.
The public intake is deliberately small: name, work email, company, and decision context. No document upload is required to start a conversation. Share only what you are authorized to provide and what is useful for the first exchange.
Information submitted through the site should be available only to people who need it to respond, support the request, or protect the intake flow. A future product workspace will have its own access model and service terms.
Do not send passwords, private keys, regulated records, or confidential attachments through the public form. We retain submitted context only for as long as there is a legitimate business or legal reason to keep it, and you can ask a question before sharing more.
The form uses server-side validation, a hidden honeypot, completion-timing checks, and strict reCAPTCHA validation where production configuration requires it. These controls reduce abuse; they are not a promise that every risk can be eliminated.
This site does not ask you to place customer files or production decision records into a public page. Product materials and fictionalized examples explain the approach; a future workspace will be governed by the agreements and controls that apply to that service.
Security requirements depend on the proposed scope, data, and operating environment. Ask us what applies to your situation before a pilot or upload. We will describe the current boundary plainly rather than imply a certification or control that has not been supplied.
Share only the context needed for an opening conversation
Never send credentials, secrets, or regulated material through the public form
Treat fictionalized examples as product illustrations
Ask for a current security answer before a pilot