Features

One model of the whole estate

The DSL covers the full span of an enterprise architecture in twenty-one entity types: strategy (goals, KPIs), business (capabilities, actors, processes, value streams), applications (systems, apps, components, AI agents), technology (environments, infrastructure), data, governance (policies, controls, standards), and security (threats, risk scenarios, vulnerabilities, trust boundaries).

Entities carry lifecycle phases with dates, business value and tech fit scores, costs with currency units, CIA security ratings, and namespaced custom attributes for anything specific to your organization, such as aws:region or pci:level. Enumerated values like criticality and lifecycle phase are enforced by the compiler, and the legal value lists come from your workspace manifest, so your vocabulary is the one that validates.

A compiler, not a drawing tool

An ANTLR grammar defines the language; a multi-phase compiler parses your .ea files, links references across the whole workspace, and validates the result semantically. Relationship verbs are typed: the compiler knows a control can mitigate a threat and a value stream cannot, and it rejects a model that says otherwise.

Problems come back as diagnostics with source context, the file and position included, the way a programming language reports errors. Duplicate workspace definitions, dangling references, and illegal enum values are caught at compile time, before anyone sees a wrong diagram.

Ten view types, compiled from one source

Views are declared in the DSL like everything else. Each one selects part of the model with include and exclude rules, filters relationships by verb and direction, picks an automatic layout, and applies style rules. Ten types cover landscapes, container models, integration topologies, KPI dashboards, capability maps, STRIDE threat models, risk heatmaps, compliance matrices, data flow maps, and attack surfaces.

Rendered views are interactive: drag nodes where you want them and the layout persists per view, surviving recompiles, with markdown callouts anchorable to any entity. Styling is rule based, so "every Mission-Critical system gets the critical treatment" is one line, applied everywhere at once.

Security architecture that computes

Threats are typed by STRIDE category and rated for likelihood and impact. Controls declare their type, framework, implementation status, and effectiveness. Trust boundaries enclose parts of the architecture. The typed verbs connect them: a threat targets an asset, a control mitigates the threat, a boundary encloses a zone.

threat thrTokenTheft "Session Token Theft" {
    category "Spoofing"
    likelihood "Medium"
    impact "High"
    mitigation_status "Mitigated"
}

control ctlStepUp "Step-Up Authentication" {
    control_type "Preventive"
    framework "NIST 800-53"
    implementation_status "Implemented"
    effectiveness "High"
}

trust_boundary tbPayments "Payment Zone" {
    boundary_type "Network"
}

thrTokenTheft targets appMobileBanking
ctlStepUp mitigates thrTokenTheft "Blocks credential replay"
tbPayments encloses systemPayments

Risk scenarios carry inherent and residual ratings separately, so a risk heatmap can show what your controls actually bought you, and a predicate like where residual_rating < inherent_rating finds every risk your controls have measurably reduced. Vulnerabilities take CVSS scores and CVE ids. The threat model, attack surface, and compliance matrix views are compiled from this data like any other view.

risk_scenario riskLedgerOutage "Ledger Unavailable During Peak" {
    inherent_likelihood "High"
    inherent_impact "Critical"
    residual_likelihood "Low"
    residual_impact "High"
    treatment "Mitigate"
}

Strategy you can hold to account

Goals carry priority and ownership. KPIs carry target values, current values, units, and trend direction, and influence the goals they measure. Capabilities are classified with TIME (Tolerate, Invest, Migrate, Eliminate) and scored for business value and tech fit, which is portfolio rationalization data your dashboard views render directly.

goal goalReduceOnboarding "Cut Onboarding Time" {
    priority "High"
    owner "Chief Digital Officer"
}

kpi kpiOnboardingTime "Median Onboarding Time" {
    target_value 5
    current_value 11
    unit "minutes"
    trend "Down"

    relationships {
        this influences goalReduceOnboarding
    }
}

AI agents are part of the architecture

Most EA tools have no vocabulary for AI systems. Scapius EA models agents as first-class entities: which model they run, their autonomy level, whether a human is in the loop, what data they read and write, and what they trigger. When a regulator or a review board asks where AI touches your estate, the answer is a compiled view, not an email thread.

agent agentFraudDetective "Fraud Review Agent" {
    model "gpt-4o"
    autonomy_level "Supervised"
    human_in_loop true
    risk "High"

    relationships {
        this reads dataLedgerTx
        this triggers procFraudReview
    }
}

A real editor experience

The VS Code extension is backed by a language server speaking LSP, which is itself backed by the same compiler that builds your views. Autocomplete knows which properties an entity accepts and which verbs are legal. Diagnostics appear as you type, with the same precision as a compile. Navigation, formatting, and refactoring work the way they do in a programming language, because the DSL is one.

CLI and API

The CLI compiles and checks workspaces from the terminal, and the same commands run in CI, so architecture review happens in pull requests. A lightweight API serves compiled views to anything that wants to render or integrate them, alongside workspace search and entity lookup:

Enterprise controls, in development

SAML single sign-on, SCIM provisioning, and role-based access control are being built now, ahead of general availability. If your organization has specific identity requirements, tell us early and we will test against them.