Skip to main content
Public BetaWe're in Public Beta. Things may break. Please report issues via the Support tab.

Core Concepts

Understanding ACE's 9 entity types and how to organize your AI's memory

What is ACE?
Universal memory infrastructure for AI systems

ACE (Adaptive Context Engine) is a PostgreSQL-powered memory system that gives AI systems the ability to remember, organize, and retrieve information across conversations and projects.

Key Features:

  • 9 Entity Types - Issues, Decisions, Work Logs, Architecture, Best Practices, Patterns, Tags, Relationships, Generic Memories
  • Knowledge Graph - Link entities with 12 relationship types
  • Namespaces - Organize memories by project, team, or context
  • REST API - 60+ endpoints for full CRUD operations
  • Semantic Search - Find memories with natural language queries
Organization & Namespaces
Flexible organization for any use case

ACE uses namespaces to organize memories. A namespace can be anything you need it to be - a project, a feature, a client, a team, or even a phase of your SDLC. Each namespace is completely isolated.

🎯 Namespaces Are Flexible

There's no "right" way to use namespaces. ACE adapts to YOUR workflow:

By Project:

  • mobile-app
  • backend-api
  • marketing-site

By Feature:

  • auth-system
  • payment-flow
  • search-v2

By SDLC Phase:

  • requirements
  • design
  • testing

By Client/User:

  • acme-corp
  • startup-xyz
  • personal

💡 Real-World Examples

Solo Developer:

One namespace per project - side-project, client-work, learning

Startup Team:

One namespace per major feature - mvp, user-onboarding, billing

Agency:

One namespace per client - acme-website, startup-app, enterprise-portal

Enterprise:

By team/domain - platform-team, frontend, security

Namespace Structure:

your-organization/
├── project-alpha/          # Namespace for Project Alpha
│   ├── issues
│   ├── decisions
│   ├── architecture
│   └── ...
├── project-beta/           # Namespace for Project Beta
│   ├── issues
│   ├── decisions
│   └── ...
└── personal/               # Personal namespace
    └── ...

🔒 Two-Layer Permission Model

ACE uses a two-layer permission system for security and flexibility:

  • Layer 1: Team Membership - Grants platform access (billing, team management, settings)
  • Layer 2: Namespace Permissions - Must be explicitly granted for each namespace
Access Control & Permissions
Understanding who can access what in ACE

ACE implements a two-layer permission model for enterprise-grade security, following the pattern used by GitHub, AWS IAM, and Google Cloud.

Layer 1: Team Membership

Controls who can use the ACE platform

  • ✓ Access to dashboard
  • ✓ View team members
  • ✓ Manage billing (if admin)
  • ✓ See namespace list
  • ✗ Read/write namespace data

Layer 2: Namespace Permissions

Controls access to specific namespaces

  • ✓ Read memories in namespace
  • ✓ Create issues, decisions
  • ✓ Update work logs
  • ✓ Manage relationships
  • ✓ Grant permissions (if admin)

4 Permission Levels (Hierarchy):

owner

Owner

Full control - manage permissions, delete namespace

admin

Admin

Grant/revoke permissions, full read/write access

write

Write

Create and edit all entity types, full read access

read

Read

View-only access, cannot create or modify data

Example Workflow:

  1. Alice joins team → Gets platform access (Layer 1)
  2. Alice can see dashboard and namespace list
  3. Admin grants Alice "write" permission on "mobile-app" namespace
  4. Alice can now create issues and work logs in mobile-app
  5. Alice still cannot access "backend-api" namespace (no permission granted)

How to Grant Permissions:

  1. Go to Dashboard → Namespaces
  2. Click the Users icon on the namespace
  3. Enter team member's email and select role
  4. Click "Grant Permission"
9 Entity Types
The building blocks of ACE's memory system

ACE organizes information into 9 specialized entity types. Each type serves a specific purpose in your AI's memory:

Issues

Track bugs, features, tasks

Decisions

Log architectural decisions

Work Logs

Daily work summaries

Architecture

System components, design

Best Practices

Guidelines, standards

Patterns

Code patterns, templates

Tags

Organize with labels

Relationships

Link entities together

Generic Memories

Any other information

Issues
Track bugs, features, tasks, and technical debt

Issues are the primary way to track work items in ACE. Use them for bugs, feature requests, tasks, technical debt, or any actionable item.

Required Fields:

  • title: Short description of the issue

Optional Fields:

  • description: Detailed explanation of the issue
  • severity: critical, high, medium, low (default: medium)
  • priority: P0, P1, P2, P3, P4 (default: P2)
  • category: bug, feature, enhancement, technical_debt, question
  • status: open, in_progress, blocked, resolved, closed
  • error_message: Error message if applicable
  • stack_trace: Stack trace for debugging
  • files_involved: Comma-separated list of affected files
  • related_issues: IDs of related issues
  • related_decisions: IDs of related decisions
  • reproduction_steps: Steps to reproduce the issue
  • expected_behavior: What should happen
  • actual_behavior: What actually happens
  • workaround: Temporary workaround if any
  • code_snippet: Relevant code snippet
  • file_path: Primary file path where issue occurs
  • line_number: Line number in file
  • tags: Array of tags for categorization

Example - Create Issue:

curl -X POST http://localhost:7777/api/v1/my-namespace/issues \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Add user authentication",
    "description": "Implement JWT-based authentication for API",
    "status": "open",
    "priority": "P1",
    "tags": ["authentication", "security"],
    "assignee": "alice@example.com"
  }'

Example - List Issues:

# List open issues
curl "http://localhost:7777/api/v1/my-namespace/issues?status=open"

# Filter by priority
curl "http://localhost:7777/api/v1/my-namespace/issues?priority=P0&priority=P1"

# Filter by tags
curl "http://localhost:7777/api/v1/my-namespace/issues?tags=security"
Decisions
Document architectural and technical decisions

Decisions capture important choices made during development. Following the Architectural Decision Record (ADR) pattern, they document the decision, rationale, alternatives considered, and consequences.

Required Fields:

  • decision: What was decided
  • rationale: Why this decision was made

Optional Fields:

  • alternatives: Array of alternative options considered
  • context: Background context and constraints
  • consequences: Expected consequences and trade-offs
  • status: proposed, accepted, deprecated, superseded
  • tags: Array of tags (e.g., "architecture", "database")

Example - Log Decision:

curl -X POST http://localhost:7777/api/v1/my-namespace/decisions \
  -H "Content-Type: application/json" \
  -d '{
    "decision": "Use PostgreSQL for production database",
    "rationale": "Better performance, ACID compliance, rich ecosystem",
    "alternatives": ["MySQL", "MongoDB", "CockroachDB"],
    "consequences": "Requires PostgreSQL hosting, industry-standard choice",
    "status": "accepted",
    "tags": ["architecture", "database"]
  }'

Best Practice: Link decisions to related issues and architecture using relationships. This creates a knowledge graph showing why systems are designed the way they are.

Work Logs
Track daily work, completed tasks, and time spent

Work Logs capture what was accomplished each day. They're useful for tracking progress, generating reports, and providing context to future AI sessions.

Required Fields:

  • date: Date in YYYY-MM-DD format
  • summary: High-level description of work done

Optional Fields:

  • tasks_completed: Array of specific tasks completed
  • context: Additional context or notes
  • hours_worked: Number of hours spent
  • tags: Array of tags for categorization
  • issue_ids: Array of related issue IDs worked on
  • decision_ids: Array of related decision IDs made

Example - Create Work Log:

curl -X POST http://localhost:7777/api/v1/my-namespace/work-logs \
  -H "Content-Type: application/json" \
  -d '{
    "date": "2025-11-18",
    "summary": "Implemented user authentication system",
    "tasks_completed": [
      "Added JWT token generation",
      "Created login/logout endpoints",
      "Wrote unit tests for auth flow"
    ],
    "context": "Completed issue #42",
    "hours": 6,
    "tags": ["authentication", "backend"]
  }'

Pro Tip: Log work at the end of each day. This creates a continuous memory for your AI, allowing it to understand what's been done and what's next.

Architecture
Document system components, APIs, and design

Architecture entities capture your system's design - components, services, APIs, data models, and how they interact.

Required Fields:

  • component_name: Name of the component
  • layer: Architecture layer (frontend, backend, database, api, infrastructure, service)
  • technology: Technology/framework used (e.g., React, PostgreSQL, FastAPI)
  • description: What the component does

Optional Fields:

  • rationale: Why this technology/approach was chosen
  • trade_offs: Trade-offs and considerations
  • dependencies: Comma-separated list of dependencies
  • tags: Array of tags for categorization

Example - Document API Service:

curl -X POST http://localhost:7777/api/v1/my-namespace/architecture \
  -H "Content-Type: application/json" \
  -d '{
    "component_name": "User Authentication Service",
    "layer": "backend",
    "technology": "Node.js with Express",
    "description": "Handles user login, registration, and session management",
    "rationale": "Express provides lightweight routing with JWT for stateless auth",
    "trade_offs": "Requires Redis for session caching, but enables horizontal scaling",
    "dependencies": "PostgreSQL, Redis, jsonwebtoken",
    "tags": ["authentication", "backend", "api"]
  }'
Best Practices
Document coding standards, guidelines, and team conventions

Best Practices capture your team's coding standards, conventions, and guidelines. They help maintain consistency and quality across your codebase.

Required Fields:

  • key: Unique identifier for the practice
  • title: Human-readable title

Optional Fields:

  • description: Detailed explanation of the practice
  • category: general, frontend, backend, security, performance, testing
  • tags: Array of tags for categorization
  • example: Code example demonstrating the practice

Example - Document Error Handling Practice:

curl -X POST http://localhost:7777/api/v1/my-namespace/best-practices \
  -H "Content-Type: application/json" \
  -d '{
    "key": "api-error-handling",
    "title": "Error Handling in API Endpoints",
    "category": "backend",
    "description": "Always use try-catch blocks in async routes with structured error responses",
    "example": "app.get(\"/api/users\", async (req, res) => { try { const users = await User.findAll(); res.json(users); } catch (err) { logger.error(err); res.status(500).json({ error: err.message }); } })",
    "tags": ["backend", "error-handling", "api"]
  }'
Patterns
Reusable code patterns and templates

Patterns store reusable code templates, design patterns, and common solutions your team uses repeatedly.

Required Fields:

  • pattern_name: Name of the pattern
  • category: design, code, testing, deployment, security
  • problem: Problem this pattern solves
  • solution: How the pattern solves it

Optional Fields:

  • use_cases: When to use this pattern
  • example: Code example demonstrating the pattern
  • pros: Advantages of using this pattern
  • cons: Disadvantages or limitations
  • tags: Array of tags for categorization

Example - Document Repository Pattern:

curl -X POST http://localhost:7777/api/v1/my-namespace/patterns \
  -H "Content-Type: application/json" \
  -d '{
    "pattern_name": "Repository Pattern",
    "category": "design",
    "problem": "Direct database access scattered throughout codebase makes testing difficult",
    "solution": "Abstract data access behind repository interfaces for testability",
    "use_cases": "When you need testable, swappable data access layer",
    "example": "class UserRepository { async getById(id) { return db.users.findById(id) } }",
    "pros": "Testability, separation of concerns, easy to swap databases",
    "cons": "Additional abstraction layer, more boilerplate code",
    "tags": ["architecture", "clean-code", "testing"]
  }'
Tags
Organize and categorize all entities

Tags are labels you can attach to any entity to categorize and organize them. They make it easy to find related items across different entity types.

Required Fields:

  • name: Tag name (lowercase, alphanumeric with hyphens)

Optional Fields:

  • display_name: Human-readable name (e.g., "PostgreSQL")
  • color: Hex color code (e.g., "#336791")
  • description: Description of what the tag represents

Example Tag Taxonomy:

By Area:

  • • frontend, backend, database
  • • api, ui, infrastructure

By Type:

  • • bug, feature, enhancement
  • • security, performance

By Priority:

  • • critical, urgent
  • • technical-debt

By Technology:

  • • react, nodejs, postgresql
  • • typescript, python

Example - Create Tag:

curl -X POST http://localhost:7777/api/v1/tags \
  -H "Content-Type: application/json" \
  -d '{
    "name": "postgresql",
    "display_name": "PostgreSQL",
    "color": "#336791",
    "description": "PostgreSQL database related items"
  }'

Pro Tip: Use consistent tag naming (lowercase, hyphenated) and create a tag taxonomy document for your team.

Relationships
Link entities together to build a knowledge graph

Relationships connect entities together, creating a knowledge graph that shows how issues, decisions, architecture, and other entities relate to each other.

Required Fields:

  • source_type: Entity type (issue, decision, memory, work_log, best_practice, architecture, pattern)
  • source_id: ID of the source entity
  • relationship_type: Type of relationship (see below)
  • target_type: Entity type of the target
  • target_id: ID of the target entity

Optional Fields:

  • metadata: JSON object with additional context about the relationship

10 Relationship Types:

implements
depends_on
blocks
relates_to
caused_by
resolves
documented_in
duplicates
supersedes
validates
reproduces

Example - Link Issue to Decision:

# Decision to use PostgreSQL implements Architecture component
curl -X POST http://localhost:7777/api/v1/my-namespace/relationships \
  -H "Content-Type: application/json" \
  -d '{
    "source_type": "decision",
    "source_id": 5,
    "target_type": "architecture",
    "target_id": 12,
    "relationship_type": "implements",
    "metadata": "{\"phase\": \"initial-setup\"}"
  }'

Example - Traverse Relationships:

# Get all entities related to decision #5
curl "http://localhost:7777/api/v1/my-namespace/relationships/traverse/decision/5"

Knowledge Graph Power: Relationships enable powerful queries like "Show me all issues that are blocked by this decision" or "Find all tests that validate this architecture component".

Generic Memories
Store any other information that doesn't fit the specialized types

Generic Memories are flexible storage for any information that doesn't fit into the other 9 entity types. Use them for user preferences, conversation context, project metadata, or any custom data.

Required Fields:

  • title: Title for the memory
  • content: Main content of the memory

Optional Fields:

  • summary: Brief summary of the content
  • context: Additional context or background
  • source: Where the information came from
  • reference_links: Array of related URLs
  • key_takeaways: Array of key points
  • action_items: Array of action items
  • importance: critical, high, medium, low (default: medium)
  • category: Category for organization (default: general)
  • tags: Array of tags for categorization
  • related_to: JSON object with related entity references
  • metadata: Any additional custom data as JSON object

Example - Store Memory with All Fields:

curl -X POST http://localhost:7777/api/v1/my-namespace/generic-memories \
  -H "Content-Type: application/json" \
  -d '{
    "title": "PostgreSQL Connection Pooling Guide",
    "content": "Use connection pooling with max_connections=100 and idle_timeout=10min for optimal performance",
    "summary": "Best practices for PostgreSQL connection pooling in production",
    "context": "Discovered during performance optimization sprint",
    "source": "PostgreSQL documentation + internal testing",
    "reference_links": ["https://www.postgresql.org/docs/current/runtime-config-connection.html"],
    "key_takeaways": [
      "Set max_connections based on workload",
      "Monitor pool exhaustion",
      "Use PgBouncer for large-scale deployments"
    ],
    "action_items": ["Configure PgBouncer", "Add monitoring alerts"],
    "importance": "high",
    "category": "database",
    "tags": ["postgresql", "performance", "production"],
    "related_to": {"decision_ids": [42], "architecture_ids": [15]},
    "metadata": {"verified_by": "alice", "last_reviewed": "2025-12-14"}
  }'

Example - Retrieve Memory:

curl "http://localhost:7777/api/v1/my-namespace/generic-memories/123"
Common Workflows
How to use ACE in your daily work

Starting a New Feature

Workflow:

  1. Create an Issue describing the feature
  2. Create a Decision for any architectural choices
  3. Document Architecture components you'll build
  4. Link the Decision → Architecture with Relationship (implements)
  5. As you work, log Work Logs daily
  6. Write Tests and link them to the Architecture
  7. Update Issue status when complete

Fixing a Bug

Workflow:

  1. Create an Issue with type "bug"
  2. Link to related Architecture component (causes relationship)
  3. Create Work Log when you start fixing it
  4. Add regression Test to prevent recurrence
  5. Link Test → Issue (tests relationship)
  6. Close the Issue

Daily Development

Workflow:

  1. Start of day: Query open Issues assigned to you
  2. Review related Decisions and Architecture
  3. As you work, update Issue status
  4. Document any new Patterns or Best Practices you discover
  5. End of day: Create Work Log summarizing progress