How the bot gathers and updates people's profiles

One of the rarest mechanisms in this project has to do not with replies but with how the system gradually assembles a person’s profile.

A profile here doesn’t look like a form filled in once. It’s an updatable model of presence: it’s refined as communication goes on and isn’t rebuilt for every line.

The key node looks like this:

if n >= PROFILE_UPDATE_EVERY:
    c.execute("UPDATE ann_profile_counters SET since_last_update=0 WHERE user_id=?", (int(user_id),))
    queue_profile_update(int(user_id))

• PROFILE_UPDATE_EVERY Sets the update threshold. The profile isn’t touched after every new message.

• since_last_update The counter shows how much new material has accumulated since the last update.

• queue_profile_update(int(user_id)) Rebuilding the profile is moved out separately. This means the system first accumulates observations and then updates the profile as a task of its own.

So the logic here isn’t reactive but cumulative: first a body of new lines is gathered, then the system decides the person can now be described more precisely.

The profile itself is stored separately:

CREATE TABLE IF NOT EXISTS ann_profiles(...)

And the grounds for it are in one more layer:

CREATE TABLE IF NOT EXISTS ann_profile_evidence(...)

• ann_profiles Stores the current description of a person inside the system.

• ann_profile_evidence Stores what this description is based on at all.

This is an important point. The project doesn’t just “form an impression” of a user. It also stores the traces this impression grew from.

So the bot works not with a one-off image of its interlocutor but with a long-refined idea of a person.

That’s what makes the profile in this project not decorative personalisation but a separate operational layer of the system.