Its Okay. I think you just misunderstand what an Interface is.
Interface is a set of rules for what additional functions a blueprint class CAN have, and what inputs and outputs those functions MUST have.
It also provides the benefit of the Does Implement Interface node which lets you know whether you can call those functions on that Actor.
So for your Interactable interface, you have a rule that anything with that interface has a function named ActorInteractStatus, and that function must take no inputs and give one boolean output.
Those are the only rules. There is no rule which says how it chooses the boolean value that it will output when you call that function.
So it is up to you to change the graph INSIDE the ActorInteractStatus function inside of your Door blueprint class, so that instead of just returning default false, it will Get the value of the door’s CanCurrentlyInteract variable and return that.
Then when Player class hits it with an interact attempt, the player class gets the Door, calls the Door’s ActorInteractStatus function. Then the Door’ ActorInteractStatus function runs (without being in the Door’s event graph anywhere. It does not need to be connected to any events, not even Beginplay or Tick, because that function runs whenever something calls that function.
So you see nothing on the Door’s event graph about CanCurrentlyInteract boolean var, and nothing about ActorInteractStatus function, because they do not run because of an event firing. The Door has them but they do not need to appear on the event graph for the door.
The only thing about those that needs to appear on any event graph is the Player class should have a call to the Door’s ActorInteractStatus function, on the Player class’s event graph just before it is trying to interact the Door.
When the player calls that function on the Door, then it will execute any blueprint code you put inside of the Door’s ActorInteractStatus function (not the Door’s execution graph)