Martin Fowler’s widely-accepted definition of Continuous Integration says:

usually each person integrates at least daily

The ambiguity around “usually” and “at least” leaves this somewhat open to interpretation, and the common question:

Is my team really doing CI?

Rather than dwelling on a specific definition of CI, I think it can be useful to focus on the reasons we care about CI. There are many benefits you might gain from CI, but let’s look at one of the big ones. In Extreme Programming Explained Kent Beck explains one of the dangers of deferred integration:

The integration step is unpredictable, but can easily take more time than the original programming. The longer you wait to integrate, the more it costs and the more unpredictable the cost becomes.

Why does deferred integration takes longer, and why is it unpredictable?

In a word: conflicts.

Not just merge conflicts of the type git complains about, though, although those certainly are salient. You can also experience behavioral conflicts. An example might be Bob adding support for a new authentication provider, meanwhile Alice is removing authentication support entirely in a parallel branch. The two changes may have no lines, or even files, in common, so they may merge cleanly, but they clearly conflict.

With this in mind, I’d reframe the question. Rather than asking “Is my team really doing CI?” I’d ask “Is my team avoiding conflicts?”

If you’re the only developer working on a project, it may be sufficient to integrate weekly, for example. On the other hand, if you’re on an especially busy project, maybe integrating 10 times daily is not sufficient to avoid painful conflicts.