Sharp EL-5500III (PC-1403) cassette tape encoding
Update:

The source code in the Pocket-Tools software package has all the answers you need:

http://pocket.free.fr/html/soft/pocket-tools_e.html

Although the way the code is written for many different models, makes it hard to read.

Original answer:

Without more context and information about what device may have created this data, there's not much of a question to answer here.

Another way of looking at the bits you have generated is like this:

11111111111111
11111111111111
11111111111111
11111111111111
11111111111111
10 1110 10 0000 1111
10 0000 10 0000 1111
10 0000 10 0000 1111
10 0000 10 0000 1111
10 0000 10 0000 1111
10 0000 10 0000 1111
10 0000 10 0000 1111
10 0000 10 0000 1111
10 1010 10 1111 1111
10 1000 10 0010 1111
10 0000 10 0000 1
10 0000 10 0101 1
10 0000 10 1100 1
10 1011 10 1111 1
10 0010 10 1000 1
10 0000 10 1011 1
10 0000 10 0000 1
10 1000 10 0010 1
10 0000 10 0101 1
10 1011 10 1010 1
10 0010 10 1001 1
10 1100 10 1011 1
10 0010 10 1000 1
10 1011 10 0000 1
10 1100 10 0000 1
10 1011 10 1000 1
10 0100 10 1011 1
10 1100 10 1000 1
10 0000 10 1011 1
10 0000 10 0000 1
10 1000 10 0111 1
10 0000 10 1100 1
10 1011 10 1011 1
10 0010 10 1001 1
10 0000 10 1011 1
10 0000 10 0000 1
10 0100 10 0001 1
10 0000 10 1100 1
10 1011 10 1001 1
10 0010 10 1001 1
10 0000 10 1011 1
10 0000 10 0000 1
10 1100 10 0100 1
10 0000 10 1100 1
10 0011 10 0010 1
10 0010 10 1000 1
10 0000 10 1011 1
10 1111 10 1111 1
10 1111 10 1111 1
10 0001 10 1110 111
10


There's a lot of repeated framing sequences of $10$ (start marker?) and $1...$ (end marker?) that don't appear to contain any information of the payload.  This sort of run length limited encoding is not uncommon in old tape formats and floppy drives, but there are so many one-off proprietary ones that you really need some device documentation or the code to examine to see how the device was transforming the data.

You can NRZI decode your bits in Octave/MatLab by doing something like:

decoded_bits = (diff(bits) == 0)


or

decoded_bits = (diff(bits) != 0)


But the regularity, in the bits you have, suggests that NRZI decoding is not the correct first step to take with the bits that you have now.

I would also be suspect of the bits minimodem is returning to you.  I would do the FSK demod in Octave to make sure that what minimodem is returning isn't bogus.  In performing the FM demod in Octave, I'd also verify the mark and space tone frequencies.  4 kHz is an oddly high frequency to use for AFSK on a cassette tape.  It implies that the expected cassette recorder isn't low end garbage that was so common in the early 1980's.