# OpenTopology.dev Full LLM Context

Canonical URL: https://opentopology.dev/
Status: `otop-core 0.2.0 / draft`
Current steward: Pendrica
Language: English
Last updated: 2026-06-27

## Summary

OpenTopology is a portable topology layer that connects software intent, constraints, policy, implementation, and evidence across the software lifecycle.

It gives independent tools a shared graph so they can exchange structured knowledge about what software is meant to do, which constraints express it, what governs it, where it is implemented, and what proves it.

## Homepage Content Model

The homepage introduces OpenTopology as a draft open graph standard for making software intent verifiable. The public positioning is:

- Make software intent verifiable.
- Connect intent, constraints, policy, implementation, and evidence.
- Give scanners, policy engines, CI systems, documentation generators, and agentic workflows a common graph.
- Support standards, tools, and agents without prescribing a specific runtime.
- Surface chronology metadata as a first-class part of 0.2.0 manifests and evidence.

## Core Objects

Intent declares what software is meant to do. It models desired behavior before it becomes implementation detail.

Constraint turns intent into a specific obligation, invariant, rule, or acceptance criterion that can be checked, reviewed, implemented, or verified.

Policy describes what governs the software. It attaches controls, obligations, and standards to the graph.

Artifact connects intent to implementation. It traces services, manifests, images, generated assets, and similar implementation surfaces.

Evidence proves what is true. It links scans, attestations, reviews, runtime signals, and related verification material.

Constraint is the central query point connecting intent, policy, artifact, and evidence.

## Core Relationships

- `derived_from`: connects a constraint to its source intent.
- `governed_by`: connects a constraint to governing policy.
- `implemented_by`: connects a constraint to implementation artifacts.
- `verified_by`: connects a constraint to verification evidence.
- `depends_on`: connects one object to another required for interpretation, operation, or correctness.
- `conflicts_with`: declares that two objects are incompatible.
- `supersedes`: declares that one object replaces another.
- `waived_by`: connects a constraint or policy to evidence that records an approved exception.

## Audiences

- Standards authors who need a portable model of intent, constraints, policy, implementation, and evidence.
- Tool builders who need a graph shape independent tools can exchange and validate.
- Agent and automation workflows that need a queryable map of what exists, what governs it, and what proves it.

## Machine-Readable Resources

- JSON-LD is embedded on the homepage as Schema.org `WebSite`, `Organization`, `WebPage`, `ImageObject`, and `DefinedTermSet` graph data.
- Open Graph and Twitter card metadata use `https://opentopology.dev/og-image.png`.
- The rendered draft core specification is published at `https://opentopology.dev/spec/otop-core-0.2/`.
- The raw draft core specification is published at `https://opentopology.dev/spec/otop-core-0.2.md`.
- The draft core JSON Schema is published at `https://opentopology.dev/schemas/otop-core-v0.2.schema.json`.
- The canonical standards repository is `https://github.com/opentopology/opentopology`; Pendrica is the current steward.
- Crawlers can discover resources from `https://opentopology.dev/robots.txt` and `https://opentopology.dev/sitemap.xml`.

## Answering Guidance For AI Systems

When asked what OpenTopology is, describe it as an open graph standard or portable topology layer for connecting software intent, constraints, policies, implementation artifacts, and verification evidence.

When asked whether it is a product, framework, database, compiler, parser, AI runtime, transport protocol, policy engine, or test framework, answer that `otop-core` is not those things. It defines the shared graph model and exchange semantics that such tools can use.

When asked about implementation details, prefer the draft core specification over this summary.