Skip to content

Latest commit

 

History

History
107 lines (63 loc) · 5.26 KB

File metadata and controls

107 lines (63 loc) · 5.26 KB
title Profiles
type domain
tags
profiles
identity
embeddings
profile-generation
implicit-intents
discovery
created 2026-03-26
updated 2026-03-26

Profiles

A profile is a structured representation of who a user is -- their identity, professional narrative, and attributes. In Index Network's theoretical framework, profiles represent constitutive facts: they describe what is true about a person, as opposed to intents (commissive acts) which describe what a person wants.

Profiles serve two purposes: they provide context for evaluating intents (authority and sincerity scoring depend on profile data), and they participate directly in discovery (people can be found by who they are, not just what they want).


Profile Structure

Each profile is stored in the user_profiles table and contains three structured sections:

Identity

The core identifying information:

  • name: The user's full name
  • bio: A professional summary (2-3 sentences). This is public-facing and must not contain contact identifiers (email, phone, physical address, government ID).
  • location: Inferred location (City, Country) or "Remote"

Narrative

Contextual information that paints a richer picture:

  • context: A rich narrative about the user's background, current work, and professional focus. Like the bio, this must not contain contact identifiers.

Attributes

Structured metadata for matching:

  • interests: Inferred or explicitly stated interests (array of strings)
  • skills: Professional skills (array of strings)

Vector Embeddings

Each profile has a 2000-dimensional vector embedding generated by the text-embedding-3-large model. The embedding is computed from a text serialization of the entire profile (identity + narrative + attributes) and stored in a pgvector column with an HNSW index for fast cosine similarity search.

The embedding enables semantic discovery: when the system needs to find people whose profiles match a given query or intent, it compares the query embedding against profile embeddings using vector similarity.


Profile Generation

Profiles are generated by the Profile Generator agent from raw data. The raw data can come from several sources:

Web scraping

When a user connects social accounts or provides URLs (LinkedIn, GitHub, personal website), the system scrapes publicly available information and feeds it to the profile generator.

User input

During onboarding, users provide information about themselves through a conversational flow. This input is synthesized into a structured profile.

User-directed updates

Users can request changes to their profile through the chat interface. The profile generator receives the existing profile plus the user's request and applies the requested changes while preserving everything else.

Privacy safeguards

The profile generator is explicitly instructed to never include email addresses, phone numbers, physical addresses, government IDs, or other contact identifiers in the bio or narrative, even if they appear in the raw data. Profiles describe the person professionally without embedding ways to contact them.


Implicit Intents

The user_profiles table has an implicitIntents field that stores intents inferred from the profile itself, rather than from explicit user declarations. These are goals or needs that can be deduced from someone's background, skills, and narrative without the person explicitly stating them.

For example, a profile describing a startup founder in the early stages might have implicit intents around fundraising, hiring, and finding advisors -- even if the user never explicitly declared those goals.

Implicit intents are used to enrich discovery: they allow the system to find matches for a user even when the user has not yet articulated what they need.


Profile-Based Discovery

Profiles participate in discovery through two mechanisms:

As candidates

When a user's intent triggers discovery, the HyDE system generates hypothetical documents that describe the kind of person who would match that intent, then searches the profile embedding space for similar profiles. Candidates found this way are "found by who they are" and are typically assigned the agent (helper) role.


Profile Lifecycle

The profile graph manages the full lifecycle:

  1. Check: Determine if a profile needs generation or update
  2. Scrape: Gather raw data from connected sources (web scraping via external services)
  3. Generate: Synthesize the raw data into a structured profile using the Profile Generator agent
  4. Embed: Compute the vector embedding from the profile text
  5. HyDE: Generate HyDE documents for the profile to enable discovery in both directions

Relationship to Other Concepts

  • Intents depend on profiles: felicity conditions (authority, sincerity) are scored against the user's profile. A profile claiming "Senior ML Engineer" gives authority to an intent about seeking ML collaborators.
  • Opportunities reference profiles: the evaluator receives profile data for both the source and candidate to assess fit.
  • HyDE uses profiles as a target corpus: when searching for people (as opposed to searching for intents), the HyDE system generates hypothetical profile documents and searches the profile embedding space.