I haven't solved runtime data yet. Every time I try, my tendency to demand everything during compile time ends up with me adding an additional compiler rule, and kicking off the can down the road.

When I added type constraints, it fit really well with validating values. If you specify:

  t BirthYear=Int where value>1800

Then it's pretty obvious if you get 1500 you can throw an error, and I considered doing it, but didn't want to tackle runtime validation at the time.

Maybe dealing specifically with "never send PII to the outside world", there are possible 3 things Sigil could have.

Since Effects are explicit (and Http and Filesystem are effects in Sigil), maybe validate before the effect is performed by calling a function to see if a particular type (Ssn) is not empty or straight up validate the value of every field.

Or with topologies, which is Sigil's way to specify external dependencies (I am not considering the filesystem one here). Same idea as effects, somewhere during the data flow some kinda of validation happens.

Maybe a third way would be to be able on a Type, specify where the data can go to. Something like:

  t Ssn=String where isValidSsn(value) transit logApi

`transit` in this case can tell where this type can live. Then, we can validate during compilation time if `Ssn` is only going to `logApi`, and not to the `mailApi` or any other external dependency.

Thanks for the suggestion, I will explore this idea.