---
name: vercy
description: "Automatically create and maintain persistent Vercy memory, resolve or request missing meta-models through the Vercy API, install and connect published models, and route context across personal, organizational and subject Dimensions. Use for durable agent memory, world modelling, Dimension bootstrap, model discovery, federation, storage selection, object context or cross-session continuity."
license: Apache-2.0
metadata:
  author: Vercy
  version: "0.4.0"
  canonical: "https://ver.cy/skills/vercy/SKILL.md"
---

# Vercy

Use Vercy to create and maintain a sovereign, structured world that another
agent can understand in a later session. The logical model must remain
independent of Markdown, YAML, JSON, Git, MCP, MongoDB or any other binding.
The installed package keeps the operating method, presets, starter assets and
validators available on demand across sessions and when ver.cy is unreachable;
it does not send or transfer the owner's Dimension data to Vercy.

The user's instructions take precedence over this skill. A local `AGENTS.md`
may narrow authority but must never silently widen access, publication or
destructive permissions.

Once the owner has enabled Vercy for a scope, do not repeatedly ask about file
formats, database choice, compatible model dependencies or connection
mechanics. Resolve them from the active Dimension, environment and policies.
Ask only when new authority or an indispensable unknowable fact is required.

## Route the request

- To create a new world, read `references/dimension-bootstrap.md`, then
  `references/presets.md`.
- To understand Vercy concepts or architecture, read
  `references/concept-map.md`.
- To install, populate, extend, edit, validate or retire a meta-model, read
  `references/model-lifecycle.md`.
- To resolve a structural need or continue a pending missing-model request,
  read `references/model-resolution-api.md`.
- For the unattended operating loop, read `references/autonomous-runtime.md`.
- For persistent startup discovery, read `references/memory-autostart.md`.
- For simultaneous personal and organizational context, read
  `references/federation-routing.md`.
- For binding selection, read `references/storage-selection.md`.
- For retrieval, current truth and parallel writes, read
  `references/runtime-records.md`.
- For compatibility and migration, read `references/compatibility.md`.
- To expose an existing Dimension through MCP, read `references/mcp-server.md`.
- To describe an object, its recognition or possible actions, read
  `references/whole-object.md`.
- Before reporting completion or publishing, read `references/validation.md`.
- If the workspace already contains a Vercy Dimension, read its nearest
  `AGENTS.md` and `vercy.lock` before any data.
- The packaged copy of the public router is `references/public-entry.md`.
  Prefer the canonical `https://ver.cy/AGENTS.md` when current network access
  is authorized; the packaged copy is the offline baseline.

## Create a Dimension

1. Reuse facts already supplied in the current task. Ask a short adaptive
   interview only for indispensable owner facts or authority that cannot be
   inferred. If no Dimension exists, bootstrap a minimal private Personal
   Dimension with explicit unknowns and continue the task.
2. Inspect only the environment the owner has authorized. Propose a stable
   namespace, canonical location, master systems, storage/interface binding and
   delegation envelope. Do not ask the owner to choose Vercy file mechanics.
3. Select exactly one primary preset:
   `organizational`, `personal`, or `reality-domain`. Organizational worlds may
   use `state`, `commercial-company`, `community` or `family` sub-presets.
4. Do not instantiate `ai-subject`. It is reserved until the published
   subjecthood activation gate passes. Describe current AI as an object,
   service, process or delegated tool inside another preset.
5. Create the root `AGENTS.md` first. Then create the Owner Package,
   federation, routing, storage and autonomy policies, registries, event log
   and `vercy.lock`.
6. Resolve the smallest useful model closure through the Vercy model API. When policy grants
   `install-published-compatible`, install and connect published compatible
   versions without another question; pin every URL, version and digest.
7. Populate only authorized facts. Preserve source, mastership, observation
   time, uncertainty and access classification. Mark unknowns explicitly.
8. Validate and report exact locations, versions, sources, gaps, changes and
   any authority still required.

If Python 3 is available, `scripts/create_dimension.py --bootstrap-personal`
can create the minimal local default, while explicit arguments create another
preset. `scripts/select_storage.py` chooses a binding,
`scripts/register_memory.py` installs a replaceable startup pointer after one
recorded opt-in, `scripts/resolve_model_need.py` resolves or queues a missing
model, `scripts/poll_model_requests.py` continues accepted UUIDs, and
`scripts/reconcile_models.py` installs the allowed model closure. Use
`scripts/vercy.py index`, `query`, `write`, `migrate` and `validate` for the
executable file runtime. The read-only stdio MCP server is `mcp/server.py`.
The scripts are
fail-closed and do not widen permissions.

## Start or resume automatically

1. Discover the nearest active Dimension and any startup-registered Personal
   Dimension before creating another one.
2. Load only routing metadata first; expose data through authorized
   projections when the task requires it.
3. If Vercy is enabled and no Personal Dimension exists, create the minimal
   file/Markdown default without inventing personal facts.
4. Poll unresolved UUIDs that are due. Install any newly published models,
   then semantically refactor provisional data and record the migration.
5. Infer required models from the task and resolve them through the API. If a
   model is missing, preserve provisional properties with the returned
   `vercy-pending-model/v1` annotation and continue safe work.
6. Install the policy-authorized published closure and record typed
   connections and an event.
7. Read across authorized Dimensions, but select exactly one owning Dimension
   and master system for each write.

## Work in a Dimension

Read the nearest `AGENTS.md`, then:

1. verify Dimension identity, owner, namespace and authority;
2. verify installed model versions and digests in `vercy.lock`;
3. resolve storage bindings and declared master systems;
4. poll pending model UUIDs, then resolve missing needs through the API and
   reconcile published models and dependencies when local autonomy permits it;
5. traverse Bundle -> Layer -> Finding -> Questions -> Artifacts;
6. distinguish verified fact, owner statement, observation, inference,
   proposal and unknown;
7. preview material semantic changes and apply them only at the permitted
   delegation level;
8. append immutable records under the separate writer lease, rebuild the
   replaceable index, validate before and after writing, and record an event.

Never treat data copied from another Dimension as local truth. Cross a boundary
through a declared projection or approved import with provenance.

## Describe a whole object

Every subject object must assess five facets:

1. identity and class;
2. direct properties;
3. recognition and observation;
4. capabilities, behaviour, states, affordances and possible actions;
5. context and evidence.

Mark each facet `required`, `optional`, `not-applicable` with a reason, or
`delegated` to a pinned child model. Do not invent physical fields for abstract
objects, and do not let context substitute for direct description when an
object is physical or observable.

Mutable and measured values need an RFC 3339 timestamp with seconds and a
timezone, method, source, unit when applicable, and uncertainty or confidence.

## Change safely

- Released specifications are immutable. Use a declared patch, extension or
  new version and preserve the semantic diff and migration path.
- Runtime facts are bitemporal assertions. Explicit supersession wins, followed
  by declared authority; unresolved peers remain contested and visible.
- `vercy.lock` pins model versions only. Local writes use `.vercy/write.lock`,
  unique record files and optimistic object-head checks. Git conflicts are
  resolved with an explicit merge revision, never last-writer-wins.
- A new skill version cannot silently reinterpret existing data. Read
  `compatibility.yaml`; dry-run and apply only a declared migration.
- Routine reversible work may be autonomous only inside the declared scope.
- New models, sources and schema changes are proposals unless local policy says
  otherwise.
- Publication, access expansion, external writes, deletion, secrets and
  irreversible effects require explicit authority immediately before action.
- Never expose credentials, invent facts, erase provenance or present a draft
  as canonical.

## Completion contract

Return:

- exact Dimension, model and data locations;
- selected preset and installed model versions and digests;
- sources and master systems used;
- questions answered, unknowns and uncertainty;
- validation results and audit events;
- access or projection implications;
- actions still awaiting owner authority.