Data and Trust Boundaries

Trust boundary principle

SimOracle should make trust boundaries visible without publishing sensitive implementation details. A buyer or reviewer should understand what data the workflow uses, what the system is allowed to do, what requires approval, and what is preserved for audit.

Data handling posture

• Use synthetic, public, redacted, de-identified, or explicitly approved data for public demos and early pilots
• Keep customer-specific paths, secrets, prompts, and policies out of public docs
• Label redacted intake correctly; redaction is not the same as formal de-identification
• Treat external compliance, certification, and regulatory claims as separate evidence requirements

Approval and audit boundary

• A recommendation should show the evidence it used
• A held action should show the reason it is held
• An approval should record who approved it and why
• An autonomous action should show the authority rule that allowed it
• An outcome should be tied back to the recommendation and action where practical

Public compliance posture

Public materials should describe implemented controls and intended governance posture without claiming external certifications, HIPAA readiness, SOC 2 completion, regulatory approval, or production acceptance unless those facts have current evidence.