#27 made a concept's @pii and @sensitive attributes survive import — they now travel on the schema of every property typed as that concept, where before they were dropped entirely and personal data was indistinguishable from any other value.
That closes the fidelity half. It does not yet make the marker do anything.
What is already there
Chronicle reads compliance metadata straight off a property schema. Source/Kernel/Core/Compliance/JsonComplianceManager.cs:102 walks propertySchema.GetComplianceMetadata() and dispatches on metadata.metadataType to a registered property-value handler. The shape it expects is visible in its own fixtures:
"compliance": [{ "metadataType": "PII", "details": "" }]Stage already hands its synthesized schemas to Chronicle. So the machinery for encrypting a @pii value at rest exists on both sides — the annotation joining them is the only missing piece.
What this would change
A Screenplay document that says a concept is personal would produce a modeled application whose matching values are encrypted per subject, erasable on a right-to-erasure request, and released transparently to observers and queries — the same behavior a hand-written [PII] gets today.
Without it, @pii in a .play is documentation: it round-trips, and nothing enforces it. A model imported from Screenplay silently gives weaker compliance guarantees than the equivalent model written by hand, which is the kind of difference nobody notices until it matters.
Why it was not done in #27
It drives kernel-side encryption, which needs IEncryptionKeyStorage and subject resolution wired for the modeled application. That could not be verified end to end alongside the contract work, and shipping an annotation that half-activates encryption would be worse than shipping none.
Suggested direction
- Have
SchemaSynthesizer emit the compliance annotation for a property whose concept carries @pii, mapping @sensitive to its own metadataType if one is warranted.
- Establish how the subject is resolved for a modeled application — Chronicle needs to know which person a value belongs to. This is the real design content, and it likely interacts with how a modeled slice picks its event source.
- Verify against a running store rather than a spec alone: append an event carrying a
@pii value, confirm it is unreadable at rest, confirm it is released to a query, and confirm erasure blanks it.
Step 2 is the part worth deciding deliberately. Steps 1 and 3 are mechanical once it is settled.
#27 made a concept's
@piiand@sensitiveattributes survive import — they now travel on the schema of every property typed as that concept, where before they were dropped entirely and personal data was indistinguishable from any other value.That closes the fidelity half. It does not yet make the marker do anything.
What is already there
Chronicle reads compliance metadata straight off a property schema.
Source/Kernel/Core/Compliance/JsonComplianceManager.cs:102walkspropertySchema.GetComplianceMetadata()and dispatches onmetadata.metadataTypeto a registered property-value handler. The shape it expects is visible in its own fixtures:Stage already hands its synthesized schemas to Chronicle. So the machinery for encrypting a
@piivalue at rest exists on both sides — the annotation joining them is the only missing piece.What this would change
A Screenplay document that says a concept is personal would produce a modeled application whose matching values are encrypted per subject, erasable on a right-to-erasure request, and released transparently to observers and queries — the same behavior a hand-written
[PII]gets today.Without it,
@piiin a.playis documentation: it round-trips, and nothing enforces it. A model imported from Screenplay silently gives weaker compliance guarantees than the equivalent model written by hand, which is the kind of difference nobody notices until it matters.Why it was not done in #27
It drives kernel-side encryption, which needs
IEncryptionKeyStorageand subject resolution wired for the modeled application. That could not be verified end to end alongside the contract work, and shipping an annotation that half-activates encryption would be worse than shipping none.Suggested direction
SchemaSynthesizeremit thecomplianceannotation for a property whose concept carries@pii, mapping@sensitiveto its ownmetadataTypeif one is warranted.@piivalue, confirm it is unreadable at rest, confirm it is released to a query, and confirm erasure blanks it.Step 2 is the part worth deciding deliberately. Steps 1 and 3 are mechanical once it is settled.