Is this a common design pattern?

i use the following pattern/style alot in my applications/programs and want to know if this is a common pattern that i don't know.

When i must write an app that is like a big function that get the input data from different sources, do the processing and create the output. Like the IPO Model (input-process-output).

I have one class/type that represents only my state/data which has no logic. Most of the time i name it Context, ExecutionContext or RuntimeContext. I also have multiple classes/types that contains only logic as stateless funtions (in C# static methods in static classes). After my entrypoint of the app, i create the context at first and use it then as arguments for my functions. The context holds the complate state/data of the app and all my static functions/methods manipulate the context. At the end of the functions chain and the call/execution is done and the context holds the final state if i need outputdata.

I try to create a picture that visualize these approach

The advantage of these pattern is

1. i can simple test my logic (small pieces of static functions) with unittest
2. it is not so hard to use concurrent code (only the context need threadsafe code)
3. dependencies to other systems a mostly decoupled as abstractions (interfaces) in the context (for example an IDbContext). That make the testing of a bigger scope simple

And here is now my question. Is this a common pattern? When yes, how is it called?

Thanks for every hint! :)

regards