Skip to content

Query Playground

TeamLoop’s query system goes beyond simple search. It provides temporal intelligence - the ability to query knowledge as it existed at any point in time.

TeamLoop supports four query modes, each serving different use cases:

Queries the latest version of all knowledge.

When to use:

  • “What’s our current authentication approach?”
  • “Who owns the payment service?”
  • “What decisions are active for the API?”

Example:

teamloop_query:
query: "authentication approach"
mode: "current"

Queries knowledge as it existed on a specific date.

When to use:

  • “What was our auth approach before the refactor?”
  • “What decisions were active during the Q2 incident?”
  • “What did we know when we made that choice?”

Example:

teamloop_query:
query: "authentication"
mode: "as_of"
as_of: "2024-06-15"

Shows how knowledge changed over a period.

When to use:

  • “How has our database strategy evolved this year?”
  • “What infrastructure decisions changed in Q3?”
  • “Track the authentication journey from start to now”

Example:

teamloop_evolution:
query: "database architecture"
from_date: "2024-01-01"
to_date: "2024-12-31"

Output includes:

  • Events grouped by month
  • Decision supersession chains
  • New entities added
  • Status changes

Compares knowledge state between two points in time.

When to use:

  • “What changed between Q1 and Q3 planning?”
  • “Compare our auth decisions from last year to now”
  • “What knowledge was added after the security audit?”

Example:

teamloop_compare:
query: "security decisions"
date_a: "2024-01-01"
date_b: "2024-07-01"

Output shows:

  • ➕ Added - New entities
  • ➖ Removed - Entities no longer active
  • 🔀 Superseded - Replaced decisions
  • ✓ Unchanged - Stable knowledge

Get chronological views of your knowledge:

Query by topic to see relevant events over time:

teamloop_timeline:
query: "payment processing"
limit: 20

Track a specific entity’s decision chain:

teamloop_timeline:
entity_id: "uuid-of-entity"

Shows:

  • What this decision superseded
  • What superseded this decision
  • Full lineage chain

Scenario: Something broke in production. What decisions led to this?

# 1. Find current state
teamloop_query:
query: "payment service configuration"
mode: "current"
# 2. Check what it was before the incident
teamloop_query:
query: "payment service configuration"
mode: "as_of"
as_of: "2024-11-01" # Day before incident
# 3. See what changed
teamloop_compare:
query: "payment service"
date_a: "2024-10-01"
date_b: "2024-11-02"

Scenario: Preparing for an architecture review, need historical context.

# 1. Get evolution of the system
teamloop_evolution:
query: "user service architecture"
from_date: "2024-01-01"
to_date: "2024-12-31"
# 2. Build timeline of decisions
teamloop_timeline:
query: "user service decisions"
limit: 50

Scenario: New team member needs to understand why things are the way they are.

# 1. Current state overview
teamloop_query:
query: "authentication and authorization architecture"
mode: "current"
# 2. Historical evolution
teamloop_evolution:
query: "authentication"
from_date: "2023-01-01"
to_date: "2024-12-31"
# 3. Key decision lineage
teamloop_timeline:
entity_id: "current-auth-decision-id"

Filter queries to specific integrations:

teamloop_query:
query: "API design"
sources: "github" # Only GitHub
teamloop_query:
query: "product roadmap"
sources: "notion,linear" # Notion and Linear
# Too broad
query: "decisions"
# Better
query: "database technology decisions"
# Best
query: "PostgreSQL vs MySQL decision for user service"
# When investigating past issues
mode: "as_of"
as_of: "date-before-issue"
# When preparing reviews
from_date: "quarter-start"
to_date: "quarter-end"
  1. Start with current mode
  2. Extract entities to knowledge graph
  3. Use evolution to understand history
  4. Use timeline for specific entity chains
  • First queries may be slower (fetching from integrations)
  • Subsequent queries benefit from cached knowledge
  • Temporal queries require existing knowledge graph data
  • Use sources filter to limit scope when possible