Is it an OVSF code?
Mathematica, 52 47 45 bytes
Byte count assumes CP-1252 encoding and $CharacterEncoding set to WindowsANSI (the default on Windows installations).
±___=!(±1=1>0)
a__±b__/;a!==b!||{a}==-{b}:=±a
This defines a variadic function PlusMinus, which takes the input list as a flat list of arguments and returns a boolean, e.g. PlusMinus[1, -1, -1, 1] gives True. It's theoretically also usable as an operator ±, but that operator is only syntactically valid in unary and binary contexts, so the calling convention would get weird: ±##&[1,-1,-1,1]. It will throw a bunch of warnings that can be ignored.
This will also throw a few warnings which can be ignored.
There might be away to shorten the somewhat annoying a!==b!||{a}==-{b} part, but I'm not finding anything right now. Keywords like SubsetQ and MatrixRank are simply too long. :/
Explanation
The solution basically defers all the tricky things to Mathematica's pattern matcher and is therefore very declarative in style. Apart from some golfitude on the first line, this really just adds three different definitions for the operator ±:
±___=False;
±1=True;
a__±b__/;a!==b!||{a}==-{b}:=±a
The first two rows were shortened by nesting the definitions and expressing True as 1>0.
We should deconstruct this further to show how this actually defines a variadci function PlusMinus by only using unary and binary operator notation. The catch is that all operators are simply syntactic sugar for full expressions. In our case ± corresponds to PlusMinus. The following code is 100% equivalent:
PlusMinus[___]=False;
PlusMinus[1]=True;
PlusMinus[a__,b__]/;a!==b!||{a}==-{b}:=PlusMinus[a]
By using sequences (sort of like splats in other languages) as the operands to ± we can cover an arbitrary number of arguments to PlusMinus, even though ± isn't usable with more than two arguments. The fundamental reason is that syntactic sugar is resolved first, before any of these sequences are expanded.
On to the definitions:
The first definition is simply a fallback (___ matches an arbitrary list of arguments). Anything that isn't matched by the more specific definitions below will give False.
The second definition is the base case for the OVSF, the list containing only 1. We define this to be True.
Finally, the third definition applies only to lists that can be decomposed into X ++ X or X ++ -X, and recursively uses the result for X. The definition is limited to these lists by ensuring they can be split into subsequences a and b with a__±b__ and then attaching the condition (/;) that either {a}=={b} or {a}==-{b}. Defining PlusMinus as a variadic function in this weird way via an operator saves a whopping 5 bytes over defining a unary operator ± on lists.
But wait, there's more. We're using a!==b! instead of {a}=={b}. Clearly, we're doing this because it's two bytes shorter, but the interesting question is why does it work. As I've explained above, all operators are just syntactic sugar for some expression with a head. {a} is List[a]. But a is a sequence (like I said, sort of like a splat in other languages) so if a is 1,-1,1 then we get List[1,-1,1]. Now postfix ! is Factorial. So here, we'd get Factorial[1,-1,1]. But Factorial doesn't know what to do when it has a different number of arguments than one, so this simply remains unevaluated. == doesn't really care if the thing on both sides are lists, it just compares the expressions, and if they are equal it gives True (in this case, it won't actually give False if they aren't, but patterns don't match if the condition returns anything other than True). So that means, the equality check still works if there are at least two elements in the lists. What if there's only one? If a is 1 then a! is still 1. If a is -1 then a! gives ComplexInfinity. Now, comparing 1 to itself still works fine of course. But ComplexInfinity == ComplexInfinity remains unevaluated, and doesn't give true even though a == -1 == b. Luckily, this doesn't matter, because the only situation this shows up in is PlusMinus[-1, -1] which isn't a valid OVSF anyway! (If the condition did return True, the recursive call would report False after all, so it doesn't matter that the check doesn't work out.) We can't use the same trick for {a}==-{b} because the - wouldn't thread over Factorial, it only threads over List.
The pattern matcher will take care of the rest and simply find the correct definition to apply.
Haskell, 57 bytes
q=length
f l=l==until((>=q l).q)(\s->s++map(*l!!q s)s)[1]
Given input list l, grows a OVSF code s by starting from [1] and repeatedly concatenating either s or -s, whichever makes the first element match that of l. Then, checks that the result is l at the end. This is checked once s has length at least that of l.
Some alternatives recursive structures also happened to give 57:
(s%i)l|length l<=i=s==l|j<-2*i=(s++map(*l!!i)s)%j$l
[1]%1
q=length
s%l|q s>=q l=s==l|r<-s++map(*l!!q s)s=r%l
([1]%)
q=length
g s l|q s<q l=g(s++map(*l!!q s)s)l|1>0=s==l
g[1]
Jelly, 18 16 14 11 bytes
^2/Eam2µḊ¿Ṭ
Outputs [1] (truthy) for OVSF codes, [] (falsy) otherwise.
Try it online!
Background
Like @LuisMendo's MATL answer and @xnor's Python answer, this submission verifies the input array "from the inside out".
Every (non-overlapping) pair of elements of a OVSF code of length two or higher is essentially a copy of the the first pair, either with the same signs or with both signs swapped. Likewise, every (non-overlapping) 4-tuple of elements of a OVSF code of length four or higher is essentially a copy of the the first 4-tuple, either with the same signs or with both signs swapped. The same is true for 8-tuples, 16-tuples, etc., up to the length of the OVFS code.
One way to verify this is to check all pairs for equality modulo the sign first, then remove the second element of each pair (which is now redundant information). If we repeat this process once more, we're essentially checking all 4-tuples. In the next iteration, we're comparing 8-tuples, etc.
Finally, if all the required 2k-tuples were equal modulo the sign and the array has been reduced to a singleton, it is sufficient to check if the remaining element is a 1.
How it works
^2/Eam2µḊ¿Ṭ Main link. Argument: A (array of 1's and -1's)
µḊ¿ While dequeuing A (removing its first element) yields a non-empty
array, execute the monadic chain to the left, updating A with the
return value after each iteration.
^2/ Compute the bitwise XOR of each non-overlapping pair of elements of
A. Note that 1 ^ 1 = 0 = -1 ^ -1 and 1 ^ -1 = -2 = -1 ^ 1.
For an array of even length that consists of the same pairs modulo
the sign, this returns either an array of 0's or an array of -2's.
If the length is odd, it will also contain the last element, which
is either a 1 or a -1.
E Test the elements of the result for equality. This yields 1 if the
array consists solely of 0's or solely of -2's, 0 otherwise.
a Take the logical AND of the previous result and every element of A.
This returns A if it passed the previous test, but replaces all of
its elements with 0's otherwise.
m2 Modulo 2; select every second element of A, starting with the first.
At this point, the last return value can be:
• [ ] if the input was empty
• [ 1] if the input was a valid OVSF code
• [-1] if the input was the negative of a valid OVSF code.
• [ 0] in all other cases.
Ṭ Untruth; yield an array with 1's at the specified indices.
Indexing is 1-based in Jelly, so [1] returns [1], the array with a 1
at index 1. Since the indices -1 and 0 are non-canonical, the arrays
[-1] and [0] are mapped to []. The empty array remains empty.