A few observations:

access is commutative, and it does not need to be specified that it is transative, because everyone in an access group has each others keys.

access can be gained and denied by simply changing your input state as a daily action.

All actions you could currently want to do on a given day you can do in rapid succession.

The transitive properties current effect is allowing you to change your own output if you have access to a different program.

This is an interesting and possibly deep mechanic, but I think it would work better if it wasn’t commutative.

[derrick] “The transitive properties current effect is allowing you to change your own output if you have access to a different program.”

That wasn’t the intention. Can you outline the scenario where this happens?

oh, I see. Its the login you want to match, not the input state. So your input state could be ‘qq’, my input state could be ‘Br’, and I’d have access to Brendan, because I match the login. your input is irrelevant for access, just your login. 

ok, all that stuff I said goes away.

Now, we could form an access loop if I had ‘Br’ and you had ‘de’, but that’s a very niche situation, and I’m fine with it.

I think we’re on the same page. In your construction, if your Input state was ‘Br’ and mine was ‘qq’, then I would have access to you. If I changed MY input to ‘de’, then you would have access to me—so yes, access loops are still possible as long everyone involved chooses to maintain the cycle.

ok, there is a lot of nuance here, but I’m good with it.