Atlas
Join the waitlist
Product overview

A clearer view of how software behaves

Explore the Atlas workflow through illustrative product previews. Capability labels distinguish current previews from planned work.

Prepare a demo requestRead the docs
Evaluation preview

Start with a question, then inspect the evidence.

This sample investigation shows how a workflow answer can carry source context.

runtime:investigation-session
Natural queryHow does a customer receive a refund?Run ID: #7812a
Synthesized
Step 1 · Business outcome

Refund issued to original payment method

Triggered upon settlement resolution and manager threshold validation.

Step 2 · Executable workflow sequence
  1. Validate request
  2. Check payment state
  3. Create refund
  4. Publish refund.completed
Step 3 · Participating systems and queues
  • Support PortalClient / UI
  • Orders APIGateway
  • Payments ServiceCore Domain
  • Event BusMessage Queue
Step 4 · Asserted claimVerified
"A refund requires a completed payment before dispatching payment provider calls."
Direct executable behavior
payments/refunds.ts:42-50commit 8f2c1d9
42async function validateAndIssueRefund(orderId: string, amt: number) {43const tx = await paymentStore.findSettledPayment(orderId);44if (!tx || tx.status !== 'settled') throw new InvalidStateError();45return await stripeAdapter.executeRefund(tx.providerId, amt);46}

Product capabilities

Understand how your systems behave

Explore the capabilities that connect software evidence to the business behavior it supports. Availability is labeled clearly for each area.

Deep inspectability

The behavior graph is the source of truth.

Atlas continuously compiles AST parses, database schemas, synchronous RPCs, and event topologies into a living semantic graph.

Topology Explorer: Refund Workflow

4 nodes5 edgesActive trace
  1. Client / UI

    Support Portal

    v2.19.0 · React
  2. Gateway

    Orders API

    Go 1.21 · gRPC/REST
  3. Active focusCore Domain

    Payments Service

    TypeScript · Node 20
  4. Message Queue

    Event Bus

    Kafka · refund_events

Edge inspection: Payments Service → Stripe Gateway

Verified call path
Execution target
StripeRefundAdapter.execute()
Source provenance
payments/src/adapters/stripe.ts
Confidence metric
Direct AST call path

Bi-directional tracing

Navigate from a business rule to exact code lines, or from a pull request diff to the workflows it alters.

Static vs runtime verification

Cross-reference static guarantees with distributed traces without intrusive runtime agents.

Evidence states

Trust comes from showing the work.

Confidence in automated software models must never be an opaque percentage or black box. Atlas categorizes every system claim through an explicit semantic taxonomy paired with provenance.

Verified

Direct executable behavior

Multiple consistent sources or direct executable behavior without unresolved branches.

Direct executable behavior
Supported

One strong source

One strong source with an unambiguous execution path and verified parameters.

One strong source
Inferred

Indirect evidence

Evidence strongly suggests the relationship through naming conventions or schema matches.

Indirect evidence
Conflicted

Sources disagree

Available sources disagree across repositories, specifications, or documentation.

Sources disagree
Unknown

Evidence unavailable

Required information could not be found or repository permissions restrict visibility.

Evidence unavailable
Divergence case study #408

Claim: “Chargeback window is strictly 90 days across all merchant tiers”

Conflicted Status
Source A: Code Implementationpayments/rules.ts:18
// Global limit enforced
const MAX_CHARGEBACK_WINDOW_DAYS = 90;

Compiled into runtime assertion in billing validator logic.

Source B: Commercial Terms Markdowndocs/merchant-terms.md:44
"Enterprise tier merchants retain a chargeback review period of up to 120 days from invoice timestamp."

Customer-facing documentation updated 14 days ago by Sales Ops.

Unified understanding

One model. The right depth for every role.

A single unified behavioral model projected into the precise vocabulary needed by leadership, product teams, and engineers.

Projection mode:Lossless semantic abstraction

Business Rule Integrity

Every SLA, customer promise, and financial limit mapped to whether software actually enforces it.

✓ Refund ceiling: $1,000/day
✓ Policy evidence linked

Compliance & Audit

Export audit-ready evidence proving policy enforcement without requesting engineering hours.

Export: Policy Control Evidence
Status: Evidence links available

Exception Management

Track which customer tiers have bypass permissions and unreviewed edge-case triggers.

Known exceptions
Unresolved gaps
Behavior change history

Know what changed in behavior, not just what changed in code.

Code diffs show characters. Atlas shows how real business rules and workflow expectations shift between commits.

PR #1482Author: @marcus-eng

Update auto-refund threshold for tier-1 accounts

base: v2.4.1 → head: v2.5.0
Before (v2.4.1)commit e3ff19c
rule.auto_refund_limit = $250
rule.requires_supervisor = false

Automated instant refund triggered unconditionally for eligible claims under $250.

After (v2.5.0)commit d4a1f62
rule.auto_refund_limit = $500
rule.requires_supervisor = (fraud_score > 0.15)

Limit raised to $500, but introduces a conditional fraud check branch requiring supervisor review.

Impacted nodes:
  • Orders API
  • Payments Service
  • Fraud Engine
2 claims updated · 1 claim added

Merged behavior verified against the master branch. Not yet in production.

Product roadmap

More context for every change

Follow how proposals, implementation, and connected systems fit together. Roadmap items below show what is in preview and what is planned.

  • Planned

    RFC and implementation traceability

    Review how proposals relate to later code and system behavior.

  • Preview

    Change intelligence

    Inspect an illustrative behavior comparison across revisions.

  • Planned

    Integration coverage

    Bring more source and event context into the evidence model.

Explore a possible evaluation

Discuss your systems, evidence sources, and the questions you need to answer.

Prepare demo requestRead the docs
Enterprise governance

Private software demands explicit controls.

Atlas will require explicit controls for private repositories and sensitive technical context. Deployment and compliance requirements will be validated with initial customers.

Permission-aware retrieval

Users only receive explanations referencing repositories and branches they explicitly have read access to in GitHub.

Repository access inheritance

Inherits repository permissions directly from GitHub access controls and organization rules.

Secret scrubbing & exclusions

Detect secrets and exclude configured sensitive files and source patterns before analysis begins.

Complete auditability

Detailed logging of every query, view inspection, and citation export to trace software understanding activity.

Tenant isolation & encryption

Dedicated tenant data isolation and encrypted transport for all code indices and semantic graphs.

Configurable model-provider controls

Control which source data may be sent to model providers and define provider-specific handling policies.

Read the security approach