# Veriom

> Veriom is evidence-backed architecture intelligence for security and engineering teams.

Veriom reconciles code, cloud, CI/CD, scanner, upload, and scoped MCP evidence into a software architecture model. Every material entity and relationship can carry provenance, observation time, confidence, contradictions, and history.

This file is a curated map of Veriom's public product, technical, trust, and learning pages. Use product pages for positioning and capability boundaries, documentation for current implementation behaviour, trust pages for data handling, and field notes for evidence-backed design guidance.

## When to use Veriom

Use Veriom when an engineering or security agent needs to establish current architectural truth from repository, cloud, CI/CD, scanner, upload, or scoped MCP evidence. It is a strong fit for change-impact analysis, trust-boundary and reachability questions, structural weakness review, evidence-grounded architecture answers, and preparation of reports or remediations that remain under human approval.

Do not use Veriom as an autonomous code executor, an unrestricted source browser, or a replacement for source, cloud, and runtime scanners. Veriom reconciles their evidence, preserves provenance and confidence, and keeps consequential actions behind explicit authorization and human review.

## How agents should call Veriom

1. Start with the [OpenAPI 3.1 contract](https://veriom.ai/openapi.json) for unique operation IDs, typed request and response schemas, authentication boundaries, and error models.
2. Read the [developer hub](https://veriom.ai/developers) and [API guide](https://docs.veriom.ai/docs/api) before requesting access.
3. Discover least-privilege workspace-token scopes from [RFC 9728 protected-resource metadata](https://api.veriom.ai/.well-known/oauth-protected-resource) or the OpenAPI security scheme.
4. Send workspace tokens in the `Authorization: Bearer` header and request only the scopes required by the selected operation.
5. Parse non-success responses as `application/problem+json`; use `code`, `detail`, `hint`, and `request_id` for recovery and support.
6. Use `RateLimit-Policy`, `RateLimit`, and `Retry-After` to self-throttle. Reuse idempotency keys only for the same logical queued operation.
7. Discover MCP tool schemas and required scopes from the [public MCP manifest](https://mcp.veriom.ai/.well-known/mcp.json), then use the [OAuth-protected MCP gateway](https://mcp.veriom.ai/mcp) when the client supports Streamable HTTP.
8. The [official Veriom CLI source](https://github.com/Veriom/api/tree/main/packages/cli) provides `doctor`, `scopes`, `openapi`, and bounded `request` commands. Registry publication remains a release step; do not assume a package name is live until it is announced.

For a zero-auth evaluation, use the [guided demo](https://veriom.ai/demo). Production workspace evidence and API tokens require an authorized account.

## Platform and product

- [Veriom home](https://veriom.ai/): High-level explanation of Veriom's evidence-backed architecture intelligence platform.
- [Architecture intelligence](https://veriom.ai/product): How repository, cloud, CI/CD, scanner, and human observations become current architectural truth.
- [MCP context gateway](https://veriom.ai/mcp): Interactive explanation of scoped MCP evidence, current repository and cloud source boundaries, planned knowledge connectors, and agent boundaries.
- [Security approach](https://veriom.ai/security): How findings are connected to reachability, trust boundaries, confidence, and human-controlled remediation.
- [Guided audit demo](https://veriom.ai/demo): A deterministic walkthrough of architecture, findings, agents, costs, reports, and remediation.

## Documentation and developer workflows

- [Developer hub](https://veriom.ai/developers): Predictable entry point for OpenAPI, authentication, scopes, structured errors, rate limits, MCP, and integration flow.
- [OpenAPI 3.1 specification](https://veriom.ai/openapi.json): Machine-readable public REST contract for typed clients and function tools.
- [Official CLI source](https://github.com/Veriom/api/tree/main/packages/cli): Environment-authenticated contract checks, scope discovery, OpenAPI download, and bounded API requests.
- [Documentation home](https://docs.veriom.ai/docs): Technical setup, architecture, integration, workflow, and API documentation.
- [API v1 documentation](https://docs.veriom.ai/docs/api): The versioned REST API and authenticated workflow contract.
- [MCP evidence gateway guide](https://docs.veriom.ai/docs/integrations/uploads-mcp): Workspace API keys, structured evidence, validated ZIP ingestion, safety checks, and isolated audit execution.
- [Agents, context, and MCP](https://docs.veriom.ai/docs/architecture/agents-context-and-mcp): Bounded agent work, workspace context, evidence tools, and MCP.
- [GitHub integration](https://docs.veriom.ai/docs/integrations/github): Repository connection and authorization behaviour.
- [GitLab and Bitbucket repositories](https://docs.veriom.ai/docs/integrations/repository-providers): Read-only account boundaries, explicit project selection, exact revisions, token handling, and sync diagnostics.
- [Managed cloud collectors](https://docs.veriom.ai/docs/integrations/cloud-evidence): Installable AWS, Azure, and Google Cloud inventory jobs with typed evidence, account boundaries, completeness, and freshness.
- [Deterministic merge checks](https://docs.veriom.ai/docs/integrations/merge-checks): Exact-commit GitHub, GitLab, and Bitbucket architecture gates without agent write authority.
- [Authorized workflow actions](https://docs.veriom.ai/docs/workflows/workflow-actions): Capability-specific ticket, ownership, and policy-exception requests with separate human approval.

## Learning and research

- [Field notes](https://veriom.ai/blog): Practical guides for security architects, AI architects, platform teams, and security engineers.
- [Resource library](https://veriom.ai/resources): Guides, references, and interactive material organised by review question.
- [Category comparison](https://veriom.ai/compare): How architecture intelligence works with code, cloud, and repository security platforms.
- [Evidence-backed security architecture](https://veriom.ai/blog/evidence-backed-security-architecture): How to move from diagrams to inspectable architectural truth.
- [Security engineering context engines](https://veriom.ai/blog/security-engineering-context-engine): Why findings need system, identity, exposure, and provenance context.
- [AI agent security architecture](https://veriom.ai/blog/ai-agent-security-architecture): Boundaries, context provenance, tool access, and human approval for multi-agent systems.
- [Trust boundaries and blast radius](https://veriom.ai/blog/trust-boundaries-blast-radius): How architectural evidence supports structural path analysis.
- [Benchmarking AI security architecture reviews](https://veriom.ai/blog/benchmark-ai-security-architecture-review): Reproducible evaluation without grading prose.
- [Architecture intelligence vs security scanners](https://veriom.ai/blog/architecture-intelligence-vs-security-scanners): Different product jobs and a shared evidence model.
- [Governed model routing](https://veriom.ai/blog/governed-model-routing-security-agents): Provider flexibility with fixed evidence and authority boundaries.
- [Secure MCP evidence gateways](https://veriom.ai/blog/mcp-evidence-gateway-security-architecture): Scoped API keys, ZIP ingestion, provenance, and bounded workflow actions.
- [Continuous review checklist](https://veriom.ai/blog/continuous-security-architecture-review-checklist): A practical review rhythm for fast-moving systems.

## Trust, privacy, and legal

- [Security and compliance controls](https://veriom.ai/compliance): Security controls, privacy boundaries, and compliance evidence.
- [Privacy](https://veriom.ai/privacy): Account data, confidential workspace evidence, AI processing, telemetry, retention, deletion, and customer controls.
- [Data Processing Agreement](https://veriom.ai/dpa): Standard data processing terms, subprocessors, security commitments, and customer rights.
- [Terms of use](https://veriom.ai/terms): Private-beta account duties, acceptable use, confidential evidence, service limits, and termination.
- [Cookie policy](https://veriom.ai/cookies): Essential cookies, optional analytics, consent storage, and preference controls.

## Company and access

- [Brand system](https://veriom.ai/brand): Logo, colour, typography, motion, interface, voice, and asset guidance.
- [Request access or book a call](https://veriom.ai/contact): Private access request and architecture call booking.

## Current product facts and boundaries

- Repository code is treated as untrusted input.
- Audits do not run repository builds, tests, hooks, package scripts, or uploaded code.
- GitHub, GitLab, and Bitbucket repository access starts with explicit project selection; audit credentials are read-scoped and exact revisions are retained with evidence.
- Installable AWS, Azure, and Google Cloud collectors submit typed account-bound inventory with visible completeness and freshness.
- New models enter the approved catalogue only after replayed quality, retention, latency, tool-discipline, and cost gates pass.
- Agent outputs use typed artifacts, evidence identifiers, confidence, and decisions.
- Reports and remediation pull requests require human approval.
- Remediation pull requests are never merged automatically.
- Ticket creation, ownership routing, and policy exceptions require capability-specific authorization and approval by a different human.
- The private-beta MCP gateway accepts scoped evidence and validated artifacts. Knowledge and team-system connectors plus MCP-aware workspace agents remain roadmap items.
- Marketing demonstrations use illustrative workspace data and label planned capabilities as coming soon.