01 Step
Open your workspace
Every workspace gives architects a single home for documents, entities, frameworks, and reviews. The dashboard surfaces what is live, what is in review, and what needs attention.
Private beta · invite-only FINTEXIS Studio
Architecture that documents itself
Studio is the workspace FINTEXIS uses to design, document, and govern enterprise architecture — living blocks, an interactive workspace graph, and an Architecture Review Board built in.
Trusted by architecture teams across
EnergyBankingInsuranceCritical Infrastructure
At a glance
12
Block primitives
6
Review states
EU
Data residency
< 100 ms
Document render
SOC 2
In progress
Day 0
Onboarding
Why we built it
Decks rot. Wikis fragment. Reviews drift.
Every enterprise architecture team faces the same three problems. Studio solves all of them in one place.
01
Decks rot
Architecture decisions live in slides nobody opens a month later. Studio keeps every decision discoverable, versioned, and tied to the code it shapes.
02
Wikis fragment
Confluence becomes a graveyard. Studio gives every concept — entity, requirement, decision, framework — a typed home with cross-links.
03
Reviews drift
ARB submissions get lost in email. Studio routes every change through a structured review with reviewer overlays and decision logs.
What Studio is
Three things, done well.
Living documents, an interactive workspace graph, and a built-in Architecture Review Board — the surface our own architects work on every day.
01 · Living documents
Block-based architecture documents
Studio replaces flat pages with composable blocks. Each block has its own theme, its own behaviour, and renders identically in the editor and on the published page — so what reviewers see is what readers see.
- Twelve typed block primitives, purpose-built for architecture
- Reviewer overlay layer for inline annotations
- Same renderer in editor and read view
WORKSPACE GRAPH
02 · Workspace graph
An interactive map of your architecture
Studio renders entities, services, and dependencies as a navigable JointJS graph. Click any node to jump to its document. Filter by domain, by framework, by review state.
- JointJS-powered workspace map
- Click-through to entity documents
- Filter by domain, framework, or status
03 · ARB workflow
An Architecture Review Board, built in
Submit a change. Reviewers add inline annotations on the actual rendered document. The ARB decides. The decision lives where the change lives — permanently.
- Structured submission → review → decision
- Inline reviewer overlays on rendered docs
- Decisions traceable from any future change
ARB REVIEW
SM
How it flows
A document, from blank page to published.
Scroll to walk through a real authoring session — from opening the workspace to publishing the rendered document. Every screen is from the current FINTEXIS Studio build.
studio.fintexis.com
01 of 05
02 Step
Start from a template
Pick from ADR, Service Spec, Entity Definition, Domain Map, NFR Sheet, Threat Model, Capability Map, or Integration Spec. The envelope is pre-filled, the block scaffold matches the document type.
03 Step
Compose with typed blocks
The editor renders blocks as you write them — Heading, Code, Callout, Framework, Entity reference. Each block enforces its own structure so architecture concepts get first-class treatment.
04 Step
Author with live preview and AI
Compose blocks on the left, see them render in real time on the right. Ask the AI panel for help shaping content, drafting requirements, or suggesting framework references — without leaving the document.
05 Step
Publish — or export
Publish as a polished HTML page that anyone in your organisation can read, or export to print-ready PDF with the same theming. One source, two surfaces.
Anatomy of a Studio document
Every document is a typed composition.
A Studio document is not a free-text page. It is a structured composition of typed blocks, surrounded by an architectural envelope — entity reference, ownership, version, review state, and outgoing links to the entities, requirements, and frameworks it touches.
01
ENTITY · PAYMENTS v2.4 · PUBLISHED
Payments Domain
Owner · Platform Team Context · Core Reviewed · 2 days ago
02
Callout · Decision
→ Entity / Ledger → Framework / Saga
03
Decisions · Links · Changelog
3 decisions
latest 2 days ago
7 outgoing links
3 entities · 4 frameworks
12 revisions
since 2025-09-12
01 · Header
Architectural envelope
Every document declares what it is (entity, requirement, ADR, framework reference), who owns it, what version it represents, and where it sits in the review lifecycle. The envelope is the same on every document — so readers always know what they are looking at.
02 · Body
Composed of typed blocks
The body is composed from the 12 block primitives. Each block knows what it is and how to render itself. Headings get anchor links. Code gets language-aware highlighting. Callouts get semantic emphasis. Entity references resolve to live entity cards.
03 · Footer
Decisions, ownership, links
Every document ends with the structural metadata that makes it discoverable later: outgoing links (entities, requirements, frameworks it touches), decision log, and changelog. Future architects can trace where a decision came from — not guess.
Block types in depth
Architecture concepts deserve typed blocks.
General-purpose editors give you headings, lists, and quotes. Studio gives you architectural primitives — first-class blocks for the things architects actually model: entities, requirements, frameworks, decisions. Here are four of the twelve.
Entity
A domain entity gets its own typed block — name, attributes, relations, ownership, bounded context. References to it from anywhere in Studio resolve to live entity cards. Rename it once, every reference updates.
Use when Use when modelling services, aggregates, domains, or any first-class business object.
Example Payments · Ledger · Identity · Audit
Requirement
Functional and non-functional requirements get a typed block with category, criticality, source, and acceptance criteria. Every requirement is traceable forward (to the code that implements it) and backward (to the stakeholder that asked).
Use when Use when capturing FRs, NFRs, regulatory constraints, or stakeholder asks that must survive the engagement.
Example Latency < 50ms · GDPR Art. 17 · Auditable
Framework
Reusable architecture patterns — circuit breaker, saga, CQRS, event sourcing, hex architecture — get their own block. Documents reference frameworks instead of re-explaining them. The framework block tracks where it is used.
Use when Use to anchor patterns once and reference them everywhere, with reverse-discovery built in.
Example Saga · Circuit Breaker · Outbox · Idempotent Receiver
Callout
Semantic emphasis with explicit intent — Note, Warning, Tip, Decision, Risk. Reviewers can filter for unresolved Risks. The ARB can produce decision reports straight from Decision callouts.
Use when Use to surface intent that flat prose would bury — risks, decisions, constraints, escape hatches.
Example Note · Warning · Decision · Risk · Tip
See it in action
A real product, shipping today.
Screenshots from the current build of FINTEXIS Studio. Every block, every workflow, every export — already running.
Featured
Live preview with AI panel
Compose blocks on the left, watch them render in real time on the right, and ask the AI for help shaping content — without leaving the document.
Component picker
Drop any of the 12 typed blocks into the active document.
Framework artefacts
Reference reusable architecture patterns from anywhere in the workspace.
AI authoring panel
Generate, expand, and refine block content with an architecture-aware assistant.
Document theming
Per-workspace themes — typography, spacing, brand colours, render style.
HTML publishing
Publish any document as a polished, themed HTML page — shareable, indexable.
PDF export
Export documents to print-ready PDF with the same theming as the live page.
Document creation flow
From idea to reviewed document, in five steps.
Studio's authoring flow is built around how architects actually work — starting from a template, composing typed blocks, linking to existing entities and frameworks, and routing through a structured review before publication.
01
Start from a template
Start from a template
Choose a template — ADR, Service Spec, Entity Definition, Domain Map, NFR Sheet, Threat Model. The envelope is pre-filled. The block scaffold matches the document type.
02
Compose with typed blocks
Compose with typed blocks
Drop in Heading, Code, Callout, Framework, Entity references. Each block enforces its own structure — no shapeless paragraphs that hide architecture inside prose.
03
Cross-link to your workspace
Cross-link to your workspace
Reference existing entities, requirements, and frameworks. Studio resolves every link to live content. The workspace graph picks up the new dependency automatically.
04
Submit for ARB review
Submit for ARB review
Submit the document. Reviewers add inline annotations on the rendered output. Studio surfaces missing requirements, conflicting decisions, and undocumented dependencies before the meeting.
05
Publish & version
Publish & version
ARB decides. Studio publishes the document, stamps the version, and ties the decision to every entity and framework the document touches. Future changes inherit the trail.
Starting points
Templates for the documents architects write often.
Studio ships with templates for the document types that recur across every engagement. Each template has the right envelope, the right block scaffold, and the right review path pre-configured.
ADR
ADR
Architecture Decision Record — context, decision, consequences, alternatives considered.
API
Service Spec
API surface, dependencies, SLOs, ownership, and runtime characteristics for a service.
ENT
Entity Definition
Domain entity with attributes, relations, bounded context, and ownership.
DOM
Domain Map
Bounded contexts, entity ownership, and cross-domain integration points.
NFR
NFR Sheet
Non-functional requirements with criticality, measurement method, and target values.
THR
Threat Model
STRIDE-based threat model with assets, threats, mitigations, and residual risk.
CAP
Capability Map
Business capabilities, the systems that realize them, and the gaps between them.
INT
Integration Spec
API contract, message schemas, error semantics, and back-pressure handling.
How Studio is different
Built for architecture. Not adapted to it.
General-purpose tools were designed for general-purpose writing. Studio was designed against the engagements FINTEXIS runs — and it shows in what it models, not just what it stores.
| Capability | FINTEXIS Studio | Confluence | Notion | Backstage |
|---|---|---|---|---|
| Typed architectural blocks | Yes | No | No | Partial |
| Entity model with cross-links | Yes | No | No | Yes |
| Requirements traceability | Yes | Plugin | No | Partial |
| Workspace dependency graph | Yes | No | No | Partial |
| Architecture Review Board flow | Yes | Plugin | No | No |
| Reviewer overlays on rendered docs | Yes | Partial | Partial | No |
| Decision log per document | Yes | No | No | No |
| EU data residency by default | Yes | Config | No | Config |
Who Studio is for
Designed against four kinds of architects.
Studio is shaped by the roles that engage with architecture every day. Each role gets the same workspace — but the value lands differently for each.
01
Enterprise Architect
Capability maps, domain models, target-state blueprints, and governance artifacts in one navigable workspace — with traceable decisions and an auditable trail.
- Capability and domain maps
- Target-state blueprints
- Auditable decision log
02
Software Architect
Service specs, ADRs, framework references, and reviewer-overlaid technical documents — the same workspace your engineers read, written in the same notation.
- Service specs and ADRs
- Framework references
- Workspace graph navigation
03
Engineering Lead
Living documentation your engineers actually read. Reviews that happen on the document, not in a parallel channel. Decisions linked to the code they shape.
- Living documentation
- Inline reviewer overlays
- Decisions linked to code
04
Architecture Consultant
A workspace you can stand up on day 0 of an engagement, hand over on day N, and the client can still navigate two years later — because every artifact is typed and discoverable.
- Day-0 workspace setup
- Engagement handover
- Long-tail discoverability
Trust & compliance
Built for regulated environments.
Architecture artifacts are some of the most sensitive documents an organisation produces. Studio treats them that way — with EU data residency, encryption at rest and in transit, structured audit logs, and a compliance posture built for the regulated sectors we serve.
EU data residency
All workspace data is stored in EU regions by default. Customer-specific residency options are available for the regulated sectors we serve.
Encryption at rest and in transit
TLS 1.3 in transit. AES-256 at rest. Encryption keys managed in EU-region key management services.
SOC 2 controls in progress
Studio's control framework follows SOC 2 Type II requirements. Formal attestation will follow public beta.
GDPR aligned
Data minimisation, right of erasure, and data-processing agreements as standard. DPIA support documentation available on request.
SSO / SAML on roadmap
OIDC sign-in available in beta. SAML and SCIM provisioning for Okta and Azure AD are the next identity work.
Audit logs
Every read, write, review, and decision is logged with actor, timestamp, and document version. Exportable for compliance reviews.
What's next
Studio's next twelve months.
A representative snapshot of where Studio is investing. Beta participants help us re-prioritize.
Now (in beta)
- Twelve typed block primitives
- JointJS workspace graph
- ARB submission + review flow
- Reviewer overlays on rendered docs
- Decision and changelog per document
- OIDC sign-in
Next (next 90 days)
- Template marketplace
- Git two-way sync (GitHub, GitLab)
- Jira / Linear linking
- Public read-only document sharing
- Export to PDF / DOCX
- Workspace search across all documents
Later (next year)
- Self-hosted deployment option
- SAML SSO and SCIM provisioning
- AI-assisted block authoring
- Slack and Teams notifications
- Backstage bridge
- Mobile read-only client
“Architecture is not a document. It is the structure of decisions a system carries forward. Studio is the place those decisions live.”
— FINTEXIS
Common questions
Frequently asked.
When can I try it?
Studio is in private beta. Request access via the form below — we onboard new teams every two weeks based on fit and capacity.
Is it self-hosted or SaaS?
Cloud-hosted today. Self-hosted and on-prem options are on the roadmap for regulated customers (energy, banking, public sector).
How does it compare to Confluence, Notion, or Backstage?
Studio is purpose-built for architecture: typed blocks for architectural concepts, an interactive workspace graph, and a built-in ARB workflow. General-purpose wikis don't model architecture — Studio does.
Do I need to engage FINTEXIS consulting to use Studio?
No. Studio is a standalone product. Many beta teams use it without engaging us for consulting — though it is the same workspace we use in our engagements.
What about data residency and security?
EU data residency by default. Encryption in transit and at rest. SOC 2 controls in development. We are happy to share our security posture during beta onboarding.
Is there a pricing page?
Not during private beta. Beta participants help us shape pricing. We will publish public pricing when we move to public beta.
Private beta
Request access
Tell us a little about your team. We onboard new beta cohorts every two weeks based on fit and capacity.
Have a complex architecture problem?
Studio is one of the ways FINTEXIS delivers. If you would rather start with a conversation about your architecture, we would love to hear from you.