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
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
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
Full control - manage permissions, delete namespace
Admin
Grant/revoke permissions, full read/write access
Write
Create and edit all entity types, full read access
Read
View-only access, cannot create or modify data
Example Workflow:
- Alice joins team → Gets platform access (Layer 1)
- Alice can see dashboard and namespace list
- Admin grants Alice "write" permission on "mobile-app" namespace
- Alice can now create issues and work logs in mobile-app
- Alice still cannot access "backend-api" namespace (no permission granted)
How to Grant Permissions:
- Go to Dashboard → Namespaces
- Click the Users icon on the namespace
- Enter team member's email and select role
- Click "Grant Permission"
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 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 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 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 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 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 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 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 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:
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 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"Starting a New Feature
Workflow:
- Create an Issue describing the feature
- Create a Decision for any architectural choices
- Document Architecture components you'll build
- Link the Decision → Architecture with Relationship (implements)
- As you work, log Work Logs daily
- Write Tests and link them to the Architecture
- Update Issue status when complete
Fixing a Bug
Workflow:
- Create an Issue with type "bug"
- Link to related Architecture component (causes relationship)
- Create Work Log when you start fixing it
- Add regression Test to prevent recurrence
- Link Test → Issue (tests relationship)
- Close the Issue
Daily Development
Workflow:
- Start of day: Query open Issues assigned to you
- Review related Decisions and Architecture
- As you work, update Issue status
- Document any new Patterns or Best Practices you discover
- End of day: Create Work Log summarizing progress