Evaluate it without talking to anyone first
Technical evaluators should be able to form a view before a call is booked. Documentation, API reference and implementation guides are here.
Product documentation
Concepts, module guides and workflows for teams running ArchtSoft.
- Architecture model concepts
- Module reference — all ten modules
- Approval workflows and versioning
- Drift detection and change impact
API reference
Endpoints, schemas and authentication for integrating ArchtSoft into an existing toolchain.
- REST API reference
- Authentication and tenancy
- Webhooks and event subscriptions
- Export formats and audit extracts
Whitepapers
Longer-form arguments for architecture as a governed, enforced asset.
- Architecture as a control plane
- Why modernisation programmes do not reduce technical debt
- Governing AI-generated code in regulated environments
- Simulating architecture before implementation
Implementation playbooks
Practical guides for getting from first model to governed lifecycle.
- Modelling your first current-state architecture
- Introducing approval gates without stalling delivery
- Migrating existing architecture documentation
- Rolling out agent-driven development safely
Written as modules stabilise, not ahead of them
ArchtSoft documentation is written against what the platform actually does today. Where a module is still moving, the documentation for it is held back rather than published and left to rot, because stale documentation for a governance product is worse than none — it teaches people a workflow that no longer exists and erodes trust in everything beside it.
That means the public set is incomplete and will stay incomplete for a while. If you are evaluating ArchtSoft and need something that is not published yet, ask: we will send the current internal draft, clearly marked as a draft, rather than a placeholder page. Evaluators consistently find that more useful than a polished document describing an aspiration.
Three things are available immediately on request regardless of module status: the security architecture overview, the STRIDE threat model summary, and the NIST 800-53 control matrix with its current coverage scoring. Those are the documents procurement and security reviews ask for first, and they describe implemented behaviour rather than planned behaviour.
Questions evaluators actually ask
Sixteen direct answers on what ArchtSoft is, how it governs AI coding agents, how it compares to enterprise architecture tools and coding assistants, security posture and product stage.
Still have a question?
Send it over. You will get an answer from someone who builds the product, not from a sales development queue.