Is there a design pattern for one input passed to n methods that each return the input for the next method

I'd like to know if there is a design pattern for this problem:

One input is used to construct an object (via constructor or via method return I don't care), that object is feed to the next method or constructor. This is repeated on a user specified set of processors, obviously throwing exceptions if there is a break in the chain of required inputs for the processors.

The output of all, some or none of the implemented processors is the same object.

I've got about 6 processors planned, possibly more in future.

Composition: I'm not sure I like the composition design pattern because not every object is intended to be an output of this process and I can't think how to not output null values without the user knowing it's going to be null.

Chain of responsibility: Chain of responsibility is the way to go according to what I've heard however I'm not sure i understand it. Is this design pattern suggesting to pass n function pointers to a function that runs through each? If so, I'm not sure how to setup the function that gets passed n function pointers.

my attempt:

I've got two interface that are inherited by n classes ie (FirstProcessor, FirstInput, FirstOutput, SecondProcessor, SecondOutput, ThirdProcessor,.., NProcessor, NOutput)

    IChainedOutput
    {
        IChainedOutput Input {get;} 
        FinalOutputOBj GetFinalOutput()
    }

    IChainedProcessor
    {
        IChainedOutput Run(IChainedOutput previousOutput)
    }

used like this:

    IChainedProcessor previous = FirstProcessor(originalInput)

    foreach(IChainedProcessor processor in processorList.Skip(1)
    {
        IChainedOutput current = processor.Run(previous)

        previous = current;       
    }

    FinalOutputObj output = previous.GetFinalOutput();

Problems:

1. FinalOutputObj is coupled with all the processor implementations which is bad. It's not comprised of all the IChainedOutput child class members but uses a good subset to calculate other values.
2. FinalOutputObj is being composed in a bad way and I don't see how I can escape from outputting null values if the list of processors does not contain every processor implemented.
3. There is a lot of downcasting in the constructors of the child classes which is a red flag for oop. However, the inputs for each block of processing logic are completely different. First input is a couple of vectors, second input is the output of the first which includes a handful of custom types and more vectors, etc
4. Each IChainedOutput contains the reference to the inputs used to create it. currently there is one to one mapping input to processor but i'm not sure in future. And this is more bad downcasting.
5. I'd like to not have to perfectly organise the list of processors, makes it too easy for other developers to make mistakes here. so the next one selected should be the one that has the correct constructor.