
Separate Keys
THE TOWER / SEPARATE KEYS
Shared hardware is not shared authority.
Follow the cover into the actual system. The art gives the work a world; the engineering below shows what runs, what has been tested, and what still needs evidence.
Read the engineering01 / THE QUESTION
How do two systems share compute without sharing permission to act?
J-Bot owns business operations. Twilight has a separate operator room and creative lane. Different workspaces and state paths are part of that design, but a visual split—or even a folder split—does not by itself prove credential or process isolation.
02 / THE SYSTEM
What the build has to hold together.
- 01Responsibility
J-Bot and Twilight answer different operational questions.
- 02State
Their working spaces and durable state are tracked separately.
- 03Authority
Customer records, approvals, sending, and business actions must remain behind their own controls.
- 04Verification
Recovery has been exercised. Permissions, service identities, and negative-access tests are the separate checks needed for a stronger isolation claim.
03 / THE CURRENT RECORD
What we can say today.
J-Bot and Twilight run as distinct services with separate state paths. Both have returned after service restart, full host reboot, and state restore in lab exercises. Recovery supports continuity; the authority boundary needs its own access evidence.
04 / THE LIMIT
What the cover cannot prove.
Separate folders and separate personalities are not a security boundary. This issue does not assert that every secret, permission, cross-service call, or failure path has been independently verified.
05 / NEXT RECEIPT
What belongs beside this chapter.
Publish the redacted recovery receipts alongside service identities, access rules, and a small negative-access test matrix. Show continuity and authority as separate claims.