How it works

A studio's working week, played against a real database

A walkthrough of the portal: an empty account; a picked document shown back before it is sent; the upload with a progress estimate; the confirmation naming what was kept; records filling in one by one; a warning that a health test result runs out nine days before a booking; the consent screen; a shoot-day conflict; the list of places the studio refers people to when a health test result runs out; performer-to-performer chat; everything held on one person gathered into a single list; and the log of who has read the file.
A minute, no sound, loops on its own. These screens are drawn — it is a tour of what the product does, not a recording of a live account. The transcript underneath is the opposite: a real run, quoted.

Every line below came out of a real PostgreSQL database, in order, on 1 August 2026 — 27 steps against 32 migrations. Nothing is staged. The refusals in amber are the database saying no, quoted exactly.

The people are invented and there is no real media, no identity document and no studio named anywhere in it. The clinics in the tour are invented too — every studio keeps its own list, and this software ships with none.

  1. JOINING THE STUDIO

  2. 01 Sam follows the studio’s link and applies as Sam, who wants to work
  3. application submitted
  4. no date of birth asked for. that belongs in the encrypted vault later, attached to real id,
  5. not sitting in an application queue where it proves nothing.
  6. 02 Sam pokes around to see what else applying got them as Sam
  7. nothing. no studios, no roster, no other performers
  8. applying grants you exactly nothing until somebody says yes
  9. 03 The studio reads the application and approves it as the coordinator
  10. 1 waiting: "Sam Placeholder" — "Available weekends, happy to travel."
  11. approved, and Sam is on the roster
  12. Sam is now on the roster as "talent" — free to write their own profile
  13. one transaction. it cannot put someone on the roster without recording why.
  14. 04 Approving the same application twice as the coordinator
  15. Refused:refused — already answered
  16. database said: "this application has already been answered"

  17. THE RECORDS VAULT

  18. 05 Rae files her own records as Rae, a performer
  19. two records filed — an ID and a signed release
  20. the sensitive part is encrypted before it reaches the database — the key never lives here
  21. 06 The studio checks what Rae has on file as the coordinator
  22. the studio CANNOT open Rae’s records — not one row is visible to it
  23. there is no staff read policy on that table at all. that absence is the design.
  24. but it CAN see proof: 2 on file · ID yes · release yes · records form no
  25. proof, never contents. that is the whole product in one line.
  26. 07 Rae checks who has been looking as Rae
  27. 1 entry in her activity log: "chain_status" touching ["record_type","expires_on"]
  28. field names and counts. never values. she sees every look, always.
  29. 08 A staff member from another studio tries Rae as the outsider
  30. Refused:refused proof about a performer who isn’t theirs
  31. database said: "not authorized"

  32. EXPIRY NOTICES

  33. 09 Jo files a record that lapses in 10 days as Jo, another performer
  34. one record on file, expiring soon
  35. 10 studio.queue_expiring_record_notices() runs, same as the 8:30am cron as the daily job
  36. 1 notice queued — Jo, whose record lapses inside the 30-day window
  37. one row per person, not per record. someone with three lapsing documents still gets one message.
  38. 11 The same job runs again, later the same morning as the daily job
  39. 0 queued this time
  40. this is the point, not a bug: Jo was already told inside the cooldown window. without this,
  41. a daily cron against a record lapsing in three weeks sends twenty-one identical emails, and
  42. twenty-one identical emails is how a warning becomes something people stop reading.

  43. THE SHOWROOM

  44. 12 A fix request goes on take-04 at 00:32 as the coordinator
  45. fix request raised against the clip at a timecode
  46. 13 The coordinator tries to approve it anyway as the coordinator
  47. Refused:refused — only the owner approves
  48. database said: "only the studio owner can approve"
  49. 14 The owner tries to approve the clip while the fix is open as the owner
  50. Refused:(!) refused — you cannot approve past an open fix request
  51. database said: "cannot approve while 1 fix request(s) are still open"
  52. this is the Showroom earning its keep. no amount of clicking gets round it.
  53. 15 The note gets addressed and the flag closed as the coordinator
  54. fix request resolved
  55. 16 Now the owner approves both as the owner
  56. the still is approved for release
  57. the clip is approved too, now it’s clean

  58. THE GALLERY AND THE LINK

  59. 17 An asset with an open fix request is added to the release gallery as the owner
  60. Refused:refused — it has an open fix request against it
  61. database said: "asset 40000000-0000-4000-8000-000000000002 is not approved for release — clear its fix requests and have the owner approve it first"
  62. enforced by the database, so no screen anywhere can route around it
  63. 18 The approved still goes in, and a link is made as the owner
  64. added to the gallery
  65. share link minted, labelled for whoever it’s going to
  66. 19 Someone with no account opens it as a stranger with the link
  67. the link opens: gallery "Selects for release", 1 item
  68. it returns a storage path — "10000000-0000-4000-8000-000000000001/30000000-0000-4000-8000-000000000001/setup-01.jpg" — never a public URL.
  69. the app signs a short-lived URL per request, which is why revoking works instantly.
  70. 20 The owner kills the link as the owner
  71. link revoked
  72. 21 They try the same URL again as the same stranger
  73. Refused:the link is dead
  74. database said: "this link is no longer available"
  75. Refused:and a token that never existed says exactly the same thing
  76. database said: "this link is no longer available"
  77. identical messages — you cannot use this to hunt for real links

  78. TALENT CHAT

  79. 22 A thread is opened for the shoot as the coordinator
  80. thread created and both performers added
  81. 23 Someone outside the studio is added to the thread as the coordinator
  82. Refused:(!) refused — chat never reaches outside this studio
  83. database said: "chat is limited to people in this studio — 20000000-0000-4000-8000-000000000009 is not a member"
  84. this guardrail is why the feature is lawful. it lives in the database, not in a form.
  85. 24 Rae sends a message — twice, because her signal dropped as Rae
  86. sent
  87. Refused:the retry does not create a second copy
  88. database said: "duplicate key value violates unique constraint "chat_messages_author_id_client_id_key""
  89. 1 message in the thread, not 2 — shoots happen where reception doesn’t
  90. 25 Jo reports a message and blocks the sender as Jo
  91. report filed for a human to read
  92. block applied
  93. the block reads as active from Jo's side: true
  94. and from Rae’s side too — a block that only worked one way would be worse than none

  95. TAKING A COPY OF YOUR OWN FILE

  96. 26 Rae uses "get a copy" and downloads everything held on her as Rae
  97. the export is logged before the file is handed over, not after
  98. doctrine 2.1: that write is awaited, never fired off alongside the response. an export nobody
  99. can account for is worse than an export that never happened.
  100. 27 Rae checks her own activity view afterward as Rae
  101. "You downloaded a copy of your data" — the row names her as both subject and actor
  102. that is the whole point of the row. the person who did NOT download their file is the one
  103. who needs to see it — an attacker who gets into her email once cannot take a copy without
  104. leaving this behind.

Every refusal above came from the database itself, not from a screen — so no screen anywhere, and no future one, can route around it.

Swap in real media, real accounts and real people. The flow is unchanged.

Sign in to the portal →