Ever shrinking number sequence

Question

Below is a list of number sequences which follow a specific rule from one to the next. The first seven sequences are written out already. Can you deduce the next one?

1011111110111111011000
001111110011111001000
00111110001111000000
0111111001111100000
011111000111100000
01111000011100000
0111000001100000
???????????????

To assist in the solving process, I have made another sequence with a different beginning number.

1010010111101001001001  
111011111111101101101  
11001111111100100100  
1000111111100000000  
100111111110000000  
10111111111000000  
1111111111100000  
???????????????

Hint:

Remember the base this puzzle uses, as well as another thing that involves parity.

Answer 1

The next value is:

111100001110000

Explanation:

We notice that most of the lines are simply the result of a bitwise AND operation of the successive digits of the prior line. For line 1 (1011111110111111011000), we have:
1&0 = 0
0&1 = 0
1&1 = 1
1&1 = 1
Continuing, we get line 2 in its entirety:
001111110011111001000
And line 3:
00111110001111000000
But then to get line 4, we must use OR:
0|0 = 0
0|1 = 1
1|1 = 1
Continuing we get line 4:
0111111001111100000
Back to AND for line 5:
011111000111100000
And line 6:
01111000011100000
And line 7:
0111000001100000

So what's the rule? Use AND unless we are parsing line 3?
This seems somewhat arbitrary. What else do we have?

The sequence began with a substring of pi's digits (1011111110111111011000 in base 2 is 3141592 in base 10)
Note that the the first few digits are mostly ODD, but digit # 3 is EVEN.
Since digit 7 is even (a 2), we should treat it like digit 3, and compute using OR.
Thus line 8, the mystery line, is the result of OR operations on the prior line:
0111000001100000 becomes:
111100001110000

This is not quite certain due to the limited size of the data set, but thanks to the second provided sequence, we can repeat the process and see that it checks out, using the even/odd parity of the second provided number. (Happens to be 2718281, OR-AND-AND-OR-etc.)

Answer 2

Edit: With the new information, I have an algorithm which seems to produce the right results in all cases, but is surely not what the author intended.

My rule is:

Compare the 2nd bit with the 15th bit in the sequence.
If they are both zero:
A => Replace substring 01 with 11 and then remove last bit.
Otherwise:
B => Replace substring 10 with 00 and then remove last bit.

Following this rule, the first set of sequences follow

B B A B B B

to produce the given sequences, and the last sequence

has to be B, so gives 011000000100000

The second set of sequences follows the pattern

A B B A A A

to produce the given sequences, and the last sequence

is again a B, so gives 111111111100000

---

Right now, my best guess is:

111100001110000

with the following rule:

On lines which are not multiples of 4, convert any 01 substring to 00 and then remove the leading digit of the sequence. On lines which are multiples of 4, convert any 01 substring to 11 and then remove the trailing digit of the sequence.

This is less an answer, and more a collection of observations, because I'm not sure where to go.

First, as per some comments, I noticed that

The first sequence is binary for the decimal number 3141592, but I can't find any other references to pi in the sequence.

This sequence is also strange because the change from one line to the next can easily be altered by a change of view. For example, for most steps:

We can change 10 to 00 and then remove trailing digit

OR

We can change 01 to 00 and then remove leading digit

I also notice that the title generally applies no matter how we look at the sequence, but then:

From line 3 to line 4, the sequence definitely increases in value if the sequences have numerical values, even if there are padding zeroes on either end, and even if the binary is big-endian or little-endian, but the sequence length itself is the only thing that's shorter/smaller

I've tried a number of solutions that involve:

subtracting a binary number and then either left-bitshifting the answer or right-bitshifting the subtrahend to go again, with mixed success, but this still doesn't account for the change from line 3 to line 4.

Which leads me to ask myself:

Is there a way to interpret the sequences so that line 4 is distinctly smaller than line 3 in a non-length way?

But also:

What causes line 4 to increase instead of decrease like all other lines?
Is it that it is line 4 (which lead to the "every fourth line" argument)?
Is it that in the first two lines, a set of 1's disappears, but line 3 doesn't manage that, so line 4 is punished? Why aren't any subsequent lines punished, then?

Answer 3

The next sequence is

111100001110000

---

Each sequence

replaces either the leading or trailing zero from each substring of $1$s. If the line number is evenly divisible by $4$ (e.g. $n \mod 4 = 0$) then the leading zero is replaced with a one (e.g. $0011100$ becomes $011100$). Otherwise, the trailing zero is replaced with a one (e.g. $0011100$ becomes $0011110$).

Additionally, each sequence

removes the last character from the sequence before it (e.g. $0011100$ becomes $001110$, if we ignore the additional work we're supposed to do).

If we do this line by line, we get:

1011111110111111011000
001111110011111001000
00111110001111000000
0111111001111100000
011111000111100000
01111000011100000
0111000001100000
111100001110000
11100000110000
1100000010000
100000000000
110000000000
10000000000
0000000000

From here, we can proceed no further since

line 14 is comprised of all zeros.

Additionally, line two, in particular, throws you off because

The last digit is dropped, and it makes it seem like the first $1$ was translated into a zero instead, but it wasn't.

Furthermore, line twelve is problematic because

it requires a leading $1$ to be added; I simply inferred that it should just push the entire value to the right. However, it could be that the line simply dropped the last value instead, in which case we'd reach all zeros on line 13 instead of line 14.