Real-time architecture mapping for engineering teams shipping across interconnected, service-heavy systems.
STRAND maps every service, dependency, and change in your stack into a single living model. When something shifts whether it's a deploy, a config update, or a new service, the map reflects it immediately across your entire workspace.
The system is built around four actions: map your services, trace dependencies, scope changes, and read impact. No backlog. No ceremony. No diagrams that go stale.
| Concept | What it means |
|---|---|
| Service | Any node in your architecture: API, worker, database, external integration |
| Dependency | A directed edge between two services indicating a runtime relationship |
| Change | Any deploy, config update, or rollback logged against a service |
| Analysis | Automatic blast-radius calculation triggered on every change |
STRAND creates a workspace automatically when you sign up. Your workspace is where all services, changes, and team activity live.
Workspaces support multiple environments. Services, changes, and health signals are all scoped per environment. A service registered in production does not automatically appear in staging.
Add engineers, SREs, and stakeholders to your workspace. Access is role-scoped.
| Role | Access |
|---|---|
| Owner | Full workspace control, billing, API key management |
| Admin | Manage services, members, and environments |
| Engineer | Log changes, view analysis, register services |
| Viewer | Read-only access to all workspace data |
Every node in your architecture begins as a registered service. Registration is the source of truth for what STRAND knows about your stack.
| Field | Type | Notes |
|---|---|---|
| name | string | Unique within the environment |
| version | string | SemVer or arbitrary tag |
| environment | string | Must match a configured environment |
| tags | string[] | Used for filtering and grouping in the UI |
Dependencies form the edges of your architecture graph. STRAND uses them to calculate blast radius and trace change propagation.
A dependency is a directed edge from one service to another. If the upstream fails, the downstream is affected. Criticality determines how the relationship is weighted in impact analysis.
Health signals update the live status of each service in the dependency graph in real time.
| State | Meaning |
|---|---|
| healthy | Operating within expected parameters |
| warning | Degraded: latency or error rate elevated |
| critical | Failing: downstream services at risk |
| unknown | No signal received within the TTL window |
STRAND marks a service as unknown automatically if no signal arrives within the configured TTL window (default 5 minutes).
Every deploy, config update, or rollback is logged as a change. Changes are the unit of analysis in STRAND.
| Type | When to use |
|---|---|
| deploy | New version pushed to an environment |
| config | Environment variable or runtime config changed |
| rollback | Service reverted to a prior version |
| hotfix | Unplanned patch applied directly to production |
When a change is logged, STRAND traverses the dependency graph to identify all affected downstream services and their risk level.
Analysis runs automatically on every change. The result is a ranked list of affected services, each scored by risk level based on dependency type, current health, and historical change data.
| Level | Condition |
|---|---|
| high | Hard dependency, service currently healthy — maximum blast radius |
| medium | Soft dependency or service already in a degraded state |
| low | Indirect dependency (2+ hops) or isolated service |
Reports are exportable as JSON or PDF from the analysis panel, or via /v1/changes/:id/analysis.
Rollbacks are logged as a change type and immediately update the service version in the dependency graph.
STRAND restores the previous version reference and re-runs impact analysis against the rolled-back state, giving your team a clean post-incident snapshot of the system.
All API requests are authenticated via bearer token. Tokens are workspace-scoped and managed under Settings → API Keys.
Query, register, and update services programmatically via the REST API.
| Method | Path | Action |
|---|---|---|
| GET | /v1/services | List all services in workspace |
| POST | /v1/services | Register a new service |
| GET | /v1/services/:id | Fetch a single service |
| PATCH | /v1/services/:id | Update name, version, or tags |
| DELETE | /v1/services/:id | Remove service from the graph |
Log, query, and manage changes programmatically. Changes trigger analysis automatically on creation.
| Method | Path | Action |
|---|---|---|
| GET | /v1/changes | List all changes in workspace |
| POST | /v1/changes | Log a new change |
| GET | /v1/changes/:id | Fetch a single change |
| PATCH | /v1/changes/:id | Update status (e.g. rolled_back) |
| GET | /v1/changes/:id/analysis | Fetch impact analysis report |