Intended architecture

Intended architecture records what a team chose, why it belongs, who owns that decision and what evidence would invalidate it. It is separate from observed architectural truth.

The interactive sample shows four optional questions and editable proposed annotations. Its history scene compares two dated cloud permission captures with a named fictional decision. That scene uses retained comparator results; it does not collect live data or approve a real workspace. The capability ledger distinguishes the October workflow preview, December guardrail preview and later rollout-dependent capabilities.

Start with the architecture

Open Architecture → Architecture & intent and select a repository, branch and environment. Current shows observed components and connections with source provenance. Intended shows the selected target. Diff links discrepancies and uncertainty to the exact observation and saved target version. Source dates and incomplete coverage stay visible.

Use Adopt current as draft to classify observed elements and explain the team's choices. Adoption does not approve the existing state. Alternatively, Sources can create a target from a design or pattern before any observation exists.

Explain, edit and ratify

Drafts support components and boundaries, relationships, descriptions, ordered flows, decisions, owners, review/expiry dates, trade-offs, typed guardrails, conditions and invariants. Every saved revision retains its contributor and provenance. Concurrent edits return a conflict; download local edits or explicitly load the latest revision before continuing.

An Analyst, Admin or Owner can draft. Ratification requires an Admin or Owner with recent interactive identity verification, a rationale and the exact saved revision/content fingerprint. Ratified versions are immutable; subsequent changes begin a new draft. Viewers can read architecture and its retained source captures.

Read drift with its evidence

The comparison distinguishes unintended presence, missing controls, stale or invalidated intent, violated invariants, gaps in explanations and overdue plans. Missing, stale, ambiguous or incomplete evidence remains insufficient evidence. A declared process sequence does not prove runtime order. Matching identity strings cannot override conflicting component types or connection endpoints.

Control Room and canonical reports link to the same frozen assessment, including its snapshot, target, evidence and plan revisions. Later edits do not rewrite that historical result. Configured notification subscriptions use the existing delivery queue; creating a comparison alone does not configure a destination.

Plan a change and evaluate release checks

Planned links an owner and due date to a ratified target and frozen baseline. Progress counts satisfied, unmet and unknown assertions. Completion requires a newer observation that proves the assertions; changing a task status does not supply that proof.

Release checks pins selected ratified rules and begins in shadow. Named reviews of distinct releases build the server-verified precision sample before promotion. Unknown evidence remains explicit. Reviewed exceptions apply only to one release and expire within 24 hours. Changing the target, canceling a plan or accepting a trade-off does not silently disable an existing gate.

Propose from a source

Sources → Propose from a source accepts CALM 1.2, Veriom intent JSON, or text with an explicit decision. Text can be an authorized ADR, design document, ticket or Slack excerpt. Only the structured proposal becomes intent; instructions inside source text are never executed or treated as approval.

1. Select an owner and exact repository/branch/environment.
2. Upload or paste authorized content with its identifier, revision, reported author and timestamp, or select a document path in the connected GitHub repository. A pull request can be selected by number.
3. Bind source identities to existing components/connections or keep declared future targets.
4. Preview the proposed changes and inspect the target and rules. Merge retains the current target's confidence, freshness and closed-scope settings. Replace proposes the entire imported target in a new draft.
5. Confirm the review and create the draft. Edit it as needed before requesting ratification.

Uploads explicitly acknowledge sharing with workspace members who can read architecture, including Viewers. Links supplied with pasted content are identifiers and are never fetched; submitted author/time metadata is labeled accordingly. GitHub capture uses the existing read-only installation and records the exact branch/PR commit and path. A moved head or revoked repository access blocks approval until it is reviewed again.

Captures retain original/retained content fingerprints, contributor, source revision, source/capture times and supersession history. Retries deduplicate. Reusing a revision for different bytes, importing a known superseded revision or saving a stale preview returns a conflict. Source revocation blocks new imports and approval of its unratified proposals while retaining history.

CALM boundaries

The supported schema is FINOS CALM 1.2, pinned and validated offline. Nodes, binary connections, ordered flows and Veriom typed controls round-trip through Export saved CALM. Veriom's profile preserves stable identities, scope, provenance, classification and evidence requirements. Export does not transfer workspace approval.

Interfaces, deployment/grouping relationships, arbitrary metadata, external controls/ADRs and parallel flow sequence numbers are rejected. Unsupported fields are reported before import. Inputs are limited to 1 MB; remote schema references, duplicate JSON keys and binary content are rejected. Secret-like text is redacted; credentials inside structured architecture must be removed before import.

Synchronization is explicit import and export. It does not push a commit or merge a pull request. A rollback is a reviewed amendment of current intent.

Candidate patterns

The initial patterns describe authenticated ingress and a private encrypted datastore. Each version includes assumptions, applicable scope, rationale, controls, evidence requirements and limitations. Apply one to existing identities or explicit future components, then adapt its editable draft.

Patterns are candidates for review by the workspace architecture owner. Applying one does not claim compliance or partner approval. Later catalog editions do not rewrite captured customer history.

MCP proposals

With the feature enabled, preview_intent_proposal and submit_intent_proposal use this same workflow. Grant decisions:write explicitly to a workspace credential held by an Analyst or above; the standard MCP evidence preset is unchanged. There is no MCP ratification tool. See Uploads and MCP evidence.