AI-powered architecture & engineeringEarly stage · private design partner program

Understand your system. Deliver changes with context.

Wattra builds a living architecture model from code, documentation, and team knowledge. Use shared context to investigate impact, design solutions, and coordinate implementation across repositories — including tests and documentation.

Join the Design Partner ProgramExplore the platform

Today we are building architecture investigations with design partners. Planning, diagrams, and AI implementation follow on the same model — see what's available and what's planned.

Sources → living architecture model → platform components
Illustration · sample data
  • Code
  • Docs & ADRs
  • Team knowledge
  • Contracts
  • Tools via MCPplanned

Living Architecture Model

  • Architecture Investigations
  • Planning & Specifications
  • AI Implementation & SDLCplanned
  • Living Diagrams
  • Meeting Copilotplanned
  • Context & Agent Integrationsplanned
The problem

In large systems, understanding doesn't accumulate on its own.

Coding agents and assistants keep context for the task in front of them. Changes in complex systems need something more: shared architecture context that spans repositories, shows where each conclusion came from, and stays consistent from the first question to the merged change.

Without shared architecture context

  • Knowledge is spread across repositories, documents, tickets, and people.
  • Findings from one investigation rarely reach the next one — or the implementation.
  • It is hard to tell which conclusions are confirmed, outdated, or still unknown.
  • Consequences of a change surface late — in review, testing, or production.

What Wattra specializes in

  • Connected knowledge across repositories: components, contracts, scenarios, decisions.
  • Every conclusion keeps its origin — the code, document, or discussion behind it.
  • Freshness and unknowns are tracked, so gaps stay visible instead of being filled in.
  • The same context carries from investigation through design, implementation, and review.
How the shared model works

One connected model of how your system actually works.

Each entry links components, contracts, and scenarios across repositories — and records where every statement comes from, how current it is, and what is still unknown.

What the model contains — select to see an example

billing / settlement-worker

Illustration · sample data
Responsibility
Settles paid orders and posts ledger entries
Depends on
payments-api · ledger-store
Consumes
OrderPaid event (schema v2)
Publishes
OrderSettled event → notifications
Part of
Checkout → payment → settlement → receipt
Assumption
Consumers are idempotent on order id
Constraint
No card data outside payments-api
Grounded in
SettlementWorker.cs · order-paid.schema.json · ADR-014
History
rev 214 · updated after merge a1b2c3d
Unknown
Owner of the retry policy is unconfirmed
Contradiction
Docs say v1 schema; code reads v2
  • Confirmed by source
  • Assumption
  • Unknown
  • Contradiction

Knowledge accumulates in the model itself — as linked, sourced, versioned statements your team can review. It is not training of AI model weights.

Platform

Six platform components around one living model.

Each component reads from the Living Architecture Model and adds reviewed results back to it. Statuses show what is being built now and what is still ahead.

  • Status: Current focusIn development with design partners — not generally available.
  • Status: NextNext on the roadmap; in active design.
  • Status: PlannedOn the roadmap; not yet available.
  • Status: Future visionLong-term direction for the platform.

Living Architecture Model

Components, contracts, dependencies, scenarios, and decisions — linked across repositories, with sources and freshness.

One loop across the SDLC

Every stage uses the same model — and adds reviewed results back.

Investigation results inform the design, the plan guides implementation, and what ships updates the model for the next change. Select a stage to see what it reads and what it contributes.

Update knowledge feeds the next Understand

Investigate

Status: Current focus

Reads from the model

Dependencies, consumers, and past decisions related to the change.

Adds back after review

Affected parts with reasoning, unknowns to check.

Specialized Wattra agents work on the same model and reconcile their updates before they are recorded. Delivery and feedback from operations are part of the long-term direction for the full cycle.

Example scenario

From a change request to an updated model.

A payment-system change, end to end. The investigation results shape the plan, the plan guides the repository changes, and what is merged updates the model. Later steps are planned capabilities, shown as an illustration.

  1. 1

    Change request

    Status: Current focus

    “Accept gift cards at checkout.”

  2. 2

    Impact investigation

    Status: Current focus

    checkout-web, payments-api, billing, and the OrderPaid event are affected. Balance ownership is unknown.

  3. 3

    Architecture plan

    Status: Next

    Option A: adapter in payments-api with OrderPaid v3. Ordered steps per repository.

  4. 4

    Coordinated repository changes

    Status: Planned

    payments-api adds the adapter; settlement-worker accepts v2 and v3 during migration.

  5. 5

    Tests & documentation

    Status: Planned

    Tests for checkout and settlement scenarios; contract docs updated to v3.

  6. 6

    Pull requests & review

    Status: Planned

    Two linked PRs reviewed against the plan; CI and reviewer comments addressed.

  7. 7

    Updated architecture model

    Status: Planned

    After merge, the model records OrderPaid v3 and the new adapter.

Illustration · sample data

Planned changes and open questions overlaid on today.

OrderPaid v3checkout-webpayments-apibillingordersledger-storegift-card adapterbalance store ?
  • Current
  • Proposed
  • Unknown — needs checking
  • Implemented

A · Adapter in payments-api

Proposed

Fit: Reuses authorization flow; keeps card scope unchanged.

Risk: Requires OrderPaid v3 — two consumers to migrate.

B · Separate gift-card service

Fit: Clear ownership boundary.

Risk: New settlement path; duplicates retry handling.

Plan checksCompatibilityData migrationFailure modesSecurityOperations

Facts about the current system

  • payments-api publishes OrderPaid v2
  • settlement-worker reads amountMinor
  • Card data stays in payments-api

Proposed changes

  • Add gift-card adapter in payments-api
  • Publish OrderPaid v3 alongside v2
  • Migrate settlement-worker to v3

Check results

  • Contract tests: 12 pass, 1 pending
  • Review: 2 comments resolved
  • Unknown: balance store owner
AI Implementation & SDLCStatus: Planned

From architecture understanding to coordinated implementation.

Wattra will use shared architecture context to implement changes across connected repositories, write and run tests, update documentation, and prepare changes for review. Implementation results will feed back into the architecture model.

  • Changes across multiple repositories, respecting shared contracts and dependencies.
  • Writing and running tests for the affected scenarios.
  • Updating technical documentation and architecture descriptions.
  • Preparing pull requests.
  • Addressing review comments and CI results.
  • Checking the implementation against requirements and the architecture plan.
  • Updating the model after changes are merged.

Planned flow — humans stay in control

Illustration · sample data
  1. Architecture plan
  2. Coordinated changes
  3. Tests & docs
  4. Pull requests
  5. Review & CICheckpoint
  6. Your approvalCheckpoint
  7. Merge & delivery
  8. Model updated

Who implements:specialized Wattra agents, or connected coding agents working under Wattra's coordination. The mechanism is still being designed with design partners.

No autonomous production releases: changes go through your review, CI, and approval process before merge and delivery.

Living Architecture DiagramsStatus: Next

Drill down by structure or by behaviour.

Go from the whole system to the code, or from a business scenario to the calls, events, and failure paths behind it. Every level keeps the question you started with.

Illustration · sample data

Your question · What changes if OrderPaid moves to schema v3?

System

Commerce platform

  • Payments
  • Storefront
  • Fulfilment

Answer at this level

Payments publishes OrderPaid; Billing and Fulfilment consume it.

Level 1 of 4 · structure path

Connected Context & Agent IntegrationsStatus: Planned

Context flows in both directions.

MCP and API connections work two ways: they extend what Wattra knows, and they let the coding agents your team already uses work with Wattra's architecture context.

Bring context into Wattra

Additional context from documentation, tasks, logs, databases, and other enterprise sources.

  • Documentation & wiki
  • Tasks & tickets
  • Logs & observability
  • Databases & schemas

Example source types — not confirmed integrations.

Living Architecture Model

MCP · API

Bring Wattra context to agents

Architecture knowledge, specifications, constraints, and rationale for external coding agents via MCP and API.

  • Architecture knowledge
  • Specifications & plans
  • Constraints
  • Rationale & decisions

Consumed by your coding agents — agent support is being defined.

See it in motion

Connections and drill-down, illustrated.

Animated illustrations of three capabilities working from the same model. Data and interfaces are samples, shown to explain the idea — not screenshots of a released product.

Illustration · sample data

Trace a core change across hundreds of repositories

A change to a shared core component can affect services, contracts, tests, deployment paths, and past architectural decisions across a large repository estate. Wattra investigates the relevant paths, preserves the evidence, and records what is fresh, stale, or still unknown.

Change requirement

What changes if the shared-core event contract evolves?

Investigation model:LocalCloudPersistent session — no rebuild per questionPlanInspectRecord evidenceEvaluate gaps

Repository estate

Scanning…
platform-coreorders-apibillingrisknotificationsanalyticscontract-tests
  • Confirmed by evidence
  • Inferred
  • Unknown / needs investigation
  • Stale context

Evidence ledger

  • shared-core/events/OrderSettled.cs
  • order-settled.schema.json
  • SettlementConsumerTests.cs
  • ADR-021 event versioning

Impact brief · Investigation Session saved

7

affected repos

3

event contracts

12

relevant tests

2

open unknowns

  • Fresh
  • Changed since investigation
  • Needs revalidation

Task-scoped context

Context is gathered for the task at hand; findings and their sources are not shared across the team or later SDLC stages.

Wattra

Investigate → preserve evidence → track freshness → reuse and update architecture memory.

OutcomeImpact briefEvidence ledgerPersistent contextFreshness tracking
Business contextStatus: Future vision

Architecture decisions in business context.

Connect architecture and code with business processes, team ownership, data, and enterprise goals — so teams can evaluate technical changes in the context of the business they support. Architecture and code remain the foundation.

  1. Enterprise goalsExtension
  2. Business processesExtension
  3. Teams & ownershipExtension
  4. DataExtension
  5. Architecture & codeFoundation
Status & review

What's being built now, and what's planned.

Wattra is early-stage and not generally available. Every statement in the model carries its certainty, and every result is reviewed by your team before it informs a decision.

Architecture claim

Settlement Worker consumes RefundRequested events.

  • Verified — Handler and passing test confirm consumption.
  • Inferred — Retry path inferred from configuration.
  • Unknown — Dead-letter behaviour is unconfirmed.
  • Stale — ADR predates the last contract change.
  • Contradicted — Two contract versions disagree.
SettlementWorker.csrefund-requested.schema.jsonSettlementWorkerTests.csADR-014rev a1b2c3d

Wattra keeps facts, assumptions, uncertainty, and stale knowledge visibly different.

How the knowledge stays trustworthy

  • Evidence over plausibility
  • Explicit uncertainty
  • Reviewed and versioned knowledge
  • Human review before decisions

Product status

  • Architecture Investigations — research & change impactStatus: Current focus
  • Architecture Planning & SpecificationsStatus: Next
  • Living Architecture DiagramsStatus: Next
  • AI Implementation & SDLCStatus: Planned
  • Architecture Meeting CopilotStatus: Planned
  • Connected Context & Agent Integrations (MCP, API)Status: Planned
  • Business context: processes, ownership, goalsStatus: Future vision
  • Delivery & operations feedbackStatus: Future vision

“Current focus” means in development with design partners — not generally available. Statuses are indicative and may change as we learn from partners.

Help shape architecture-aware software delivery.

We're looking for architecture and platform teams to validate Wattra on real cross-repository investigations and help shape context-driven planning, implementation, testing, and documentation.

Investigations are our current focus. Implementation and broader SDLC capabilities are planned.

Join the Design Partner Programcontact@wattratech.com