What Dilly is designed to do
- carry context across surfaces so the user does not have to restate themselves
- translate profile depth into better fit reads, better artifacts, and better next actions
- adapt the experience to mode and current career state
- keep the system useful across the long arc of a career, not only one application cycle
What Dilly should refuse to do
- collapse a person into one simplistic score that becomes their identity
- treat public visibility as the default state
- act like mode changes erase history
- let one flashy surface drift away from the profile spine and become its own disconnected product
- hide trust logic in a black box the user cannot inspect anywhere
Where trust lives
The privacy and trust proofs live on privacy.hellodilly.com. That is where data handling, AI behavior, export and delete flows, public receipts, and policy language should stay. This site explains the logic of the system, not the legal and operational proofs around it.
Where product usage help lives
The support and task-oriented guidance lives on help.hellodilly.com. That is where a user should go to figure out how to set up, troubleshoot, switch modes, or use a specific surface.
Why the split matters
If help, method, privacy, and investor narrative all blend together, the company starts to feel confused. Strong systems separate jobs cleanly. Method explains how Dilly thinks. Help explains how to use it. Privacy explains why to trust it. Investors explains why it scales.
Design consequence
Every new surface should be able to answer four questions clearly: what profile signal it reads, what state it reacts to, what context it creates next, and what trust boundary governs it.