Looking for design patterns suggestions.

[krzysztof.konopko]

I know that the informations I provide may seem limited but maybe
someone has solved similar problem.
I am new in design patterns and I am quite confused who should control
whom, how to configure particular elements checkers, how to make it
all flexible and elegant, how to encapsulate it as much as possible.

There is an API which provide a sequence of data objects.
My task is to check if this sequence is correct:
- does it have proper number of elements
- do the elements have proper data type at particular position in
sequence
- send a formatted message using API if incorrect data type is at some
position in sequence

It would be nothing interesting in this task if the sequence
requirements were fixed but it may vary:
- data type requirements may change on particular positions of
sequence
- sequence length may change (including variation above)
- some checks would be redundant because requirements for some
elements can be very similar

Good news are that the requirements are changeing statically (they are
constant for particular application release).

The sequence is provided by some API function which is state dependent
so the sequence need to be copied into some container. It might look
like this:

// API initialization
// API sequence provider initialization
// some container declaration, let's say 'sequence'

while ( void *pData = API_NextElem() )
sequence.push_back( pData );

// Now I can use some API functions to check particular elements
properities,
// e.g.:
if ( API_IsIntegerData( sequence.at( 0 ) ) )
{
API_Message( "Integer data requeired at position 0" );
return; // application should exit
}

// or

if ( API_GetDataValue( sequence.at( 0 ) ) > 3 )
{
API_Message( "Data value at position 0 should be less than 3" );
return;
}

Checkers may be more complicated and may require some information from
API.

I am not looking for complete solution but general suggestions.
Any design pattern suggestions, articles, etc., are welcomed.

Thanks in advance.