KEEP EXISTING SIGN-IN
Sign-in verifies identity; it does not grant every operation.
SEMANTIC FIREWALL · CAUSAL SECURITY SYSTEM
Successful sign-in verifies who you are. It does not authorize every operation.
I designed this system to preserve an enterprise's existing authentication and security controls without treating successful sign-in as operation-wide authorization. Before a protected operation, it evaluates whether subject, device, environment, time, work, rules and responsibility establish authority for this specific effect. Compute may propose a candidate only inside the admitted boundary.
01 / CONTROLLED PATH
Sign-in verifies identity; it does not grant every operation.
Bind subject, device, environment, time, work, rules and responsibility to one operation.
Stop on missing evidence; compute cannot invent the gap.
Compute receives only admitted work data and may only propose a candidate.
Input, version, scope and candidate cannot be swapped in transit.
The executor creates an effect only after checking a single-use grant.
Keep traceable positions for relationships, candidate, review and effect receipt.
02 / RELATIONSHIP LEGALITY
The same signed-in identity does not automatically inherit the same operation grant across devices, environments, times or work. Existing relationships retain version and source; a change rechecks only the affected relationship.
Who acts this time
Whether this device belongs to the relationship
Whether observations support this work window
Whether source data belongs to this work
What the candidate may and may not do
Who may execute, stop, repair and answer
03 / THREE PUBLIC SCENARIOS
A synthetic map shows an observation, allowed boundary and uncertainty, then relates it to the device, environment, time and work. GPS, IP or VPN alone cannot grant authority.
Identity remains valid; only this operation loses effect eligibility. The system identifies the missing environment or responsibility relation instead of letting a model invent it, then waits for rule-based revalidation.
Even after sign-in and pre-check, a candidate that adds operations, alters sources or mismatches the calculation receives no effect authority; the executor creates no file.
04 / WEBSITE FIXED-CASE DEMO
I built the website version as a fixed synthetic scenario with no visitor input. It automatically replays integration placement, missing-evidence stops and out-of-scope candidate blocks, while the public interactive walkthrough keeps its original design, code and pacing.
A fixed synthetic identity enters from the existing system. Sign-in confirms the session subject without granting every later operation.
SOURCEReconstructed as a fixed website film from the public semantic-firewall-causal-demo README and walkthrough; the public demo design and code remain unchanged.
BOUNDARYEvery subject, device, location, time, work item, candidate and result is synthetic. No credentials are collected and no model, private backend, live location, enterprise system, verifier or authorization service is connected. This is not a SaaS claim.
05 / PUBLIC BOUNDARY
I have encoded the integration sequence, relationship checks, stop conditions, same-candidate review and replay path in a public synthetic walkthrough.
This public website demonstration does not connect to real sign-in, GPS, device verification, a model, an enterprise system, an authorization service, a database or audit evidence. It makes the integration position and blocking logic visible. Any real enterprise integration must still be implemented and verified in a named environment.
I keep the private backend, rule core, full formulas, enterprise integration data and local product workspace out of the site and public repository.