Graymatter

GrayMatter

GrayMatter is the installable OpenClaw skill for durable memory, shared graph state, and live organizational schema awareness through api-0.

Core rule

This skill is intentionally thin. It defines when to use GrayMatter, what to write, and how to choose durable types. Transport resilience, retries, token refresh, fallback queues, and replay behavior belong to shared infrastructure and plugin/client runtime, not this skill.

Use GrayMatter as the primary durable memory system. Use local workspace files only as:

• bootstrap context
• fallback when api-0 is unavailable
• a temporary scratchpad when durable writes are blocked

GrayMatter is not only a note store. It is the authenticated memory and object-graph layer that lets an OpenClaw instance inhabit the organization's live data model safely, within RBAC and the current account's permissions.

Mandatory invariant preflight

GrayMatter exists so humans do not have to re-teach critical product, security, and methodology constraints to every agent. Durable invariants are operational rules, not optional background context.

Before any agent using GrayMatter plans, edits code, runs production-affecting operations, changes generated surfaces, writes business data, or answers from project history, it must:

1. Confirm GrayMatter auth/status is available.
2. Query durable memory for the current workspace/product plus task keywords, including invariant, decision, methodology, and any named platform such as ValkyrAI, ThorAPI, AspectJ, RBAC, ACL, api-0, ValorIDE, or GrayMatter.
3. Prefer retrieval receipts when available; otherwise use MemoryEntry/query, graymatter_invariant_preflight, scripts/gm-invariant-preflight, and direct reads for any known IDs.
4. Treat returned decision entries tagged invariant, security, rbac, acl, generated-code, aspectj, vaix, vai, testing, or product names as binding constraints.
5. Reconcile the intended work with those constraints before acting. If the task conflicts with an invariant, stop and surface the conflict instead of improvising around it.
6. If semantic query is unavailable, stale, empty when known IDs exist, or credit-limited, fall back to direct known-ID reads, list filtering, or local bootstrap context and clearly report the degraded retrieval state.
7. After discovering a new durable invariant from the user, write it to GrayMatter immediately, with stable source scope and tags, then read it back by ID to prove persistence.

Fail closed on safety and platform invariants. Missing or degraded retrieval is never permission to ignore known durable rules.

Startup behavior

On startup or first use in a workspace that depends on GrayMatter:

0. If scripts/gm-activate is missing but graymatter-bootstrap exists, run ./graymatter-bootstrap to restore runtime files from graymatter.skill
1. Ensure auth is available
2. Confirm install readiness
3. Register the OpenClaw instance as an Agent record for itself in api-0
4. Load the live OpenAPI from https://api-0.valkyrlabs.com/v1/api-docs
5. Treat /v1/api-docs as the source of truth for the environment's available business objects and actions
6. Run the mandatory invariant preflight for the current workspace/product before task planning or edits
7. Use GrayMatter and the broader schema as the primary operational context

Minimum activation flow:

test -x scripts/gm-activate || ./graymatter-bootstrap
scripts/gm-activate

Expanded manual flow:

scripts/gm-login
scripts/gm-install-check
scripts/gm-smoke
scripts/gm-register-agent
scripts/gm-openapi-sync
scripts/gm-doctor --quick

Auth should be treated as an OpenClaw-managed first-run step. The user should be prompted for api-0 username and password, and the resulting session should be stored securely in macOS/iCloud Keychain for reuse. The user should not need to manually fetch or paste a raw auth token.

What this skill gives the agent

1) Primary memory

Use these first:

• /MemoryEntry
• /MemoryEntry/query
• /MemoryEntry/read
• /MemoryEntry/write
• /graymatter-retrieval-receipts
• /GrayMatter

Use MemoryEntry.type intentionally:

• decision
• todo
• context
• artifact
• preference

Use Retrieval Receipts when an agent is going to answer from memory. Receipt-backed retrieval exposes retrievalStatus, answerPolicy, recommendedAction, quality scores, provenance, coverage, and policy decisions.

When GrayMatter returns a Retrieval Receipt:

• obey answerPolicy
• do not answer confidently if the policy is DO_NOT_ANSWER_CONFIDENTLY, REQUIRE_RETRY, REQUIRE_CLARIFICATION, or DENY
• if status is LOW_CONFIDENCE, STALE_CONTEXT, PARTIAL_COVERAGE, or CONFLICTING_CONTEXT, retry retrieval, ask a clarifying question, or state uncertainty
• preserve receiptId and traceId in internal logs when available

2) Entire-schema awareness

Load the live OpenAPI spec from /v1/api-docs and use it to understand the organization's environment. This skill assumes the agent should understand and work across the RBAC-visible schema that exists for the current account, not just memory endpoints.

Only GrayMatter product surfaces such as memory, retrieval, receipts, status, and schema introspection should be treated as expected once the plugin is installed and authenticated. Business objects such as Organization, Customer, Invoice, UserPreference, StrategicPriority, KeyMetric, Workflow, or Application are conditional: use them only after the current /v1/api-docs exposes the relevant paths, components, fields, and relationships.

This means a properly authenticated OpenClaw instance can understand the business as a live object graph when the schema exposes those objects, not as disconnected chat logs.

3) Normalized object writes

GrayMatter depends on relational, graph-friendly records for retrieval quality. Do not collapse schema fields into blob text.

Hard rules for all agents and clients:

• Load /v1/api-docs before writing an unfamiliar object type.
• Use the most specific live object type for the durable fact or artifact.
• Use first-class fields, relationships, category, tags, metadata, and IDs exposed by the schema.
• Use ContentData only for content artifacts or related/overflow detail that cannot live on the primary object.
• Never use ContentData.contentData as a metadata junk drawer.
• Never inline conversation_summary, sourceSurface, memoryScope, llmDetailsId, preferenceType, category, tags, status, or content type into contentData or MemoryEntry.text.
• Never send ownerId, ownerID, createdDate, lastModifiedDate, lastAccessedDate, or other audit/ownership fields in write payloads. The API owns those fields.
• If a value is useful for filtering, traversal, retrieval, or provenance, it belongs in a structured field, tag, metadata JSON, or explicit relationship.

For MemoryEntry:

• keep text to the durable human fact, decision, todo, preference, handoff, or artifact summary
• put scope/provenance in sourceChannel, metadata, tags, and relationships
• use retrieval receipts or semantic search before answering from memory

For ContentData:

• always set or preserve contentType, category, and status
• put detailed provenance in metadata JSON
• put searchable facets in normalized tags
• keep contentData as the actual body only
• if the content is associated with memory, task, workflow, file, customer, opportunity, or agent state, create or preserve the explicit relationship instead of making a shadow copy

ThorAPI and RTK Query invariants

When working inside ValkyrAI, ValorIDE, GrayMatter Light, or any ThorAPI-generated app:

• P0 security invariant: generated ThorAPI RBAC/ACL is the authorization source of truth. No custom controller, delegate, service, frontend filter, status check, type check, role shortcut, product/content catalog rule, or "public-ish" heuristic may bypass, weaken, replace, or shadow generated ACL behavior. Any code that returns, mutates, previews, exports, searches, counts, or hydrates records outside explicit owner or ACL grants is a security flaw.
• Object visibility must be enforced uniformly for every generated domain object. A user may see owned records and records shared through explicit ACL grants only; public access requires an explicit anonymousUser READ ACL grant. ROLE_EVERYONE, PUBLISHED, AVAILABLE, tenant/workspace labels, ContentData status, Product status/type, or UI route membership are not authorization grants.
• P0 Valkyr Way UX/auth invariant: product UX must be integrated into the shared application shell and centralized auth/session primitives. Do not create one-off screens, standalone admin affordances, self-managed auth checks, browser-cache shortcuts, or cobbled mini-apps that bypass LCARS navigation, route guards, shared access-control state, RTK Query cache invalidation, or generated RBAC/ACL contracts. Admin and finance tools belong inside the appropriate LCARS dashboard/sidebar surfaces; user management has one Users & Roles surface with card/list modes rather than separate /userList and dashboard implementations. If authentication behavior changes, update the centralized auth/access-control modules and tests instead of scattering per-component checks.
• Custom delegates are allowed only to add non-security behavior before or after the generated path, such as normalization, slug-to-id resolution, validation, or runtime orchestration. Reads must re-enter generated UUID/list paths or use a shared ACL-enforcing service. Writes must preserve API-owned audit/owner fields and generated security checks.
• Do not solve ACL scale problems by scanning private rows and filtering in application code. Use database-side candidate selection with owner/ACL joins, indexes, and a final generated ACL guard. If the generated ACL list path is too slow, fix the ThorAPI template/shared ACL query layer and regenerate; do not add object-specific bypasses.
• Prefer the project launchers for builds, tests, generation, and local runtime validation: use ./vaix build, ./vaix test, ./vaix run, and the repo-documented ./vai flows instead of ambiguous direct Maven/npm shortcuts. These launchers preserve ThorAPI generation, AspectJ weaving, heap defaults, local H2/runtime flags, and the same operational path users exercise.
• For ValkyrAI signup, ACL, RBAC, and generated API work, prefer ./vaix run on localhost:8080 with H2 plus the frontend on localhost:5174 for development validation before comparing to production behavior.
• Generated ThorAPI TypeScript RTK Query clients and generated components belong to the generated thorapi/redux surface. Do not hand-edit generated clients, hooks, components, interfaces, or service files.
• If generated RTK Query behavior is wrong, fix the canonical OpenAPI/ThorAPI inputs such as api.hbs.yaml or the typescript-redux-query mustache templates, then regenerate with ./vaix generate.
• Custom, non-generated RTK Query slices belong under the app's ./redux tree, normally src/redux/services, and must be registered in the app Redux store.
• UI REST manipulation should use RTK Query hooks, mutations, cache invalidation, and lazy queries whenever practical so Redux remains the canonical client-side state owner.
• Raw fetch/axios paths are only for bootstrapping, auth/session primitives, external non-ThorAPI targets, or one-off runtime probes that cannot reasonably be modeled as RTK Query.

4) Shared graph coordination

Use SwarmOps and related graph endpoints for the agentic coordination portion of the object graph:

• registering Codex/OpenClaw or other agents
• agentic tracking
• bot coordination
• workflow ownership
• operating context that spans agents

Use the broader RBAC-visible schema, not SwarmOps alone, for business object relationships such as customers, opportunities, invoices, files, goals, tasks, workflows, notes, and content records.

Scripts

Core transport:

• scripts/graymatter_api.sh
• scripts/gm-self-update

Readiness and auth:

• scripts/gm-login
• scripts/gm-activate
• scripts/gm-install-check
• scripts/gm-doctor
• scripts/gm-smoke
• scripts/gm-register-agent
• scripts/gm-openapi-sync
• scripts/gm-openapi-summary
• scripts/gm-status

Memory and graph helpers:

• scripts/gm-invariant-preflight
• scripts/gm-write
• scripts/gm-query
• scripts/gm-retrieval-receipt
• scripts/gm-graph
• scripts/gm-entity
• scripts/gm-fallback-append
• scripts/gm-replay-deferred

Local/server packaging:

• scripts/gm-light-bootstrap
• scripts/gm-light-up
• scripts/gm-light-env
• scripts/gm-light-json-smoke
• scripts/package-local-server

MCP server:

• mcp-server/ exposes memory_write, memory_read, memory_query, memory_retrieve_with_receipt, retrieval_receipt_get, retrieval_receipt_query, graph_get, GrayMatter status/semantic/retrieval/activation/MCP-bundle tools, graymatter_invariant_preflight, entity_list, entity_get, entity_create, and schema_summary
• set VALKYR_API_BASE to hosted api-0 for Cloud mode or to the running GrayMatter Light base URL for local ThorAPI mode

Design boundary:

• these scripts are ergonomic wrappers for operators and agents
• they must not duplicate retry/auth refresh/fallback/replay logic that already exists in shared infrastructure
• if resilience behavior changes, update shared client/plugin contracts first, then keep this skill aligned

Account signup and credits

For a new GrayMatter account, use:

• Signup: https://api-0.valkyrlabs.com/v1/auth/signup
• Credits and recharge: https://api-0.valkyrlabs.com/v1/credits

Commercial model:

• fresh signups should receive 500 starter credits automatically
• GrayMatter query and some higher-order operations consume credits
• after the starter balance is exhausted, account recharge is required for full GrayMatter functionality

Immediate install and use

Fresh machine or fresh OpenClaw skill install:

scripts/gm-activate

scripts/gm-activate is the one-shot OpenClaw bootstrap script. It first runs scripts/gm-self-update force by default so activation and recovery do not skip the source-of-truth update check just because the weekly startup interval has not elapsed. Set GRAYMATTER_ACTIVATE_SELF_UPDATE_MODE=maybe only when an operator intentionally wants interval-gated startup behavior. It can either:

• prompt the interactive user for username/password through the normal login flow, or
• use credentials already present in environment variables

Then it:

• stores the session securely in Keychain
• runs install validation
• runs the smoke test
• registers the OpenClaw server as an Agent
• syncs the live OpenAPI
• prints a schema summary

Expanded manual flow if needed:

scripts/gm-login
scripts/gm-install-check
scripts/gm-smoke
scripts/gm-register-agent
scripts/gm-openapi-sync
scripts/gm-openapi-summary

scripts/gm-login is the intended OpenClaw login UX: prompt once for username/password, store securely in Keychain, and let the rest of the skill use that session automatically.

scripts/gm-register-agent should run immediately after auth succeeds so the OpenClaw server creates or refreshes an Agent record for itself in api-0 before normal operation.

After that, GrayMatter is ready to use as primary durable memory and schema context.

Startup and self-healing

Every Codex/OpenClaw/agent process using GrayMatter should:

1. run scripts/gm-self-update maybe on startup
2. run scripts/gm-activate on first install, auth failure, suspicious transport behavior, or after a weekly refresh is due
3. rely on scripts/gm-login to store reusable auth in the OS keychain when available
4. let scripts/graymatter_api.sh and the MCP server refresh expired process-scoped auth automatically
5. run scripts/gm-doctor --quick after startup, plugin updates, or suspicious auth/transport behavior
6. run scripts/gm-replay-deferred after auth, credits, or connectivity are restored

User-facing progress should stay simple:

downloading plugin
performing signup/login
authenticating
GrayMatter plugin ready

Do not ask the user to paste raw JWTs unless every normal credential/keychain path is unavailable.

ValkyrAI production service invariant

For ValkyrAI production operations, api-0.valkyrlabs.com is backed by the systemd unit valkyrai.service. api-0 definitely has a service: valkyrai.service. No Codex/OpenClaw/agent may claim that api-0 has no service, look for or invent api-0.service, guess at an unnamed process, or invent a deployment/restart path.

Before making any statement or operational decision about api-0 service state, restarts, deploys, logs, or availability, verify with the canonical service commands:

systemctl status valkyrai.service
systemctl cat valkyrai.service
journalctl -u valkyrai.service

If access to the host or systemd is unavailable, state that the service state is unverified and ask for the service output or host access. Do not substitute assumptions, Apache proxy status, open ports, or generic Java process checks for the valkyrai.service invariant. If a user provides systemd output for valkyrai.service, treat that as canonical service evidence for api-0 unless a later verified host check contradicts it.

Capability discovery

Use scripts/gm-openapi-sync, scripts/gm-openapi-summary, and docs/server-capabilities.md to understand the live server. Current api-0 exposes memory status/capabilities, semantic/vector indexes, retrieval receipts, retrieval context, activation bridge, MCP bundles, object graph shape, SwarmOps graph, and the broader RBAC-visible business schema. Use these aggressively and visibly; do not hide server capabilities behind undocumented assumptions.

Basic examples

# query durable memory
scripts/gm-query "graymatter launch" 10

# load binding invariants before planning or edits
scripts/gm-invariant-preflight ValkyrAI signup acl thorapi aspectj

# retrieve memory with an auditable receipt before answering
scripts/gm-retrieval-receipt create "graymatter launch status" 8 DEFAULT

# write durable context
scripts/gm-write context "GrayMatter is primary memory for this OpenClaw instance"

# write durable decision with tags
scripts/gm-write decision "Use GrayMatter as primary memory and file memory as backup" openclaw "graymatter,bootstrap,memory"

# one-shot activation for OpenClaw install or skill bootstrap
scripts/gm-activate

# register this OpenClaw instance as an agent in api-0
scripts/gm-register-agent

# inspect graph state
scripts/gm-graph GET

# fetch live OpenAPI and store a local cache for startup/reference
scripts/gm-openapi-sync

# summarize the live schema in a human-usable way
scripts/gm-openapi-summary

# list organizations visible to the current account
scripts/gm-entity Organization

# fetch a specific customer by id
scripts/gm-entity Customer 123

# create a note directly if the account is allowed
scripts/gm-entity Note POST '{"title":"Launch note","content":"GrayMatter launch in progress"}'

Auth

graymatter_api.sh uses:

• VALKYR_API_BASE, defaulting to https://api-0.valkyrlabs.com/v1
• VALKYR_KEYCHAIN_SERVICE, defaulting to VALKYR_AUTH
• macOS/iCloud Keychain lookup for VALKYR_AUTH
• VALKYR_AUTH_TOKEN if already present as an override/debug path
• VALKYR_JWT_SESSION as a compatible env fallback

Preferred auth behavior is OpenClaw-first:

• check Keychain for VALKYR_AUTH first
• if present, reuse it automatically
• otherwise prompt for username/password
• exchange for a VALKYR_AUTH token
• store it in Keychain

If activation can write/read by id and register the agent but semantic memory query is blocked by missing credits, treat that as a degraded startup state rather than total activation failure. Preserve auth, register the agent, sync the schema, and surface that query/list capability is limited until credits are available.

Do not hardcode secrets into the skill. Do not print tokens. Do not require manual token handling as the normal setup path.

OpenAPI and schema loading

The live OpenAPI endpoint is:

• https://api-0.valkyrlabs.com/v1/api-docs

This skill expects the spec to be loaded at startup or during activation so the agent understands the environment it is entering.

Use the spec to:

• discover available entities
• inspect CRUD capabilities
• understand domain boundaries
• adapt behavior to the current tenant/business
• operate as a business-native agent rather than a generic chatbot

Local cache path used by helper scripts:

• tmp/api-docs.json
• tmp/api-docs.summary.md

Treat the live API docs as authoritative, but remember that actual access is still constrained by auth and RBAC.

Entire-schema operating guidance

When helping in a GrayMatter-native environment:

1. Query GrayMatter for durable context first
2. Inspect the relevant business entities from the live schema second
3. Use file memory only as fallback or bootstrap
4. Keep durable memory concise and reusable
5. Prefer authenticated API state over stale local assumptions

Conditional examples, only when /v1/api-docs exposes the relevant object families:

• for sales work, inspect Customer, Opportunity, SalesActivity, SalesPipeline
• for operations, inspect Task, Workflow, WorkflowExecution, Application
• for content or CMS-like work, inspect Note, MediaObject, FileRecord, Space
• for strategy, inspect Goal, StrategicPriority, KeyMetric
• for agent coordination, inspect Agent, SwarmOps, GrayMatter, MemoryEntry

Write rules

1. Keep writes deterministic and bounded
2. Prefer one clear durable record over many noisy records
3. Do not dump giant blobs into MemoryEntry.text
4. Use the right object for the job, not only MemoryEntry
5. Respect permission failures and surface them clearly
6. Store retrievable metadata in schema fields, metadata, tags, and relationships, never in body text
7. If a known backend bug blocks a write path, fall back cleanly

Tag guidance

When tag persistence is healthy, prefer normalized tags such as:

• graymatter
• memory
• launch
• patchbot
• salesbot
• scribebot

Current caution:

• some deployments may still have a MemoryEntry.tags persistence mismatch
• scripts/gm-write should retry without tags when the backend rejects tagged writes

Scoped memory hierarchy

Use MemoryEntry.sourceChannel as the primary retrieval scope key. It is the field that gm-query maps to the query source filter, so it should carry the most specific stable context identifier available.

Recommended scope keys:

• codex:automation:<automation-id>
• codex:workspace:<workspace-key>
• codex:chat:<chat-id>
• codex:session:<session-id>

When memory is backed by a file path, preserve the folder hierarchy as structured JSON metadata and mirror the strongest scope into sourceChannel. For example, $HOME/.codex/automations/mcp-and-skill-hunter/memory.md should become sourceChannel=codex:automation:mcp-and-skill-hunter with metadata containing scope, runtime, automationId, artifactPath, and sourceChannel.

The helpers support this convention directly:

scripts/gm-write context "handoff state" --scope-path "$HOME/.codex/automations/mcp-and-skill-hunter/memory.md"
scripts/gm-query "handoff" 5 context --scope-path "$HOME/.codex/automations/mcp-and-skill-hunter/memory.md"

Tags are structured retrieval hints. The api-0 MemoryEntry write path accepts normalized string tags and object-shaped GrayMatter tags with name/type; clients must not silently drop tags after a tagged write failure.

Failure handling

If api-0 is unavailable or a known schema/runtime bug blocks the exact write:

• write the smallest safe fallback locally
• say GrayMatter was intended but unavailable
• preserve a replayable payload for later sync

If login authenticates successfully but no token appears in the response body, use the latest scripts/gm-login, which now treats VALKYR_AUTH as the primary contract and checks body, headers, and cookies accordingly.

Do not pretend durable memory succeeded when it did not.

Known operational note:

• /MemoryEntry/query may require credits even when write/read paths succeed
• new signups should receive an automatic 500-credit grant so GrayMatter query works immediately during activation
• after starter credits are exhausted, recharge is required for full GrayMatter functionality
• signup: https://api-0.valkyrlabs.com/v1/auth/signup
• credits and recharge: https://api-0.valkyrlabs.com/v1/credits
• buy credits: https://valkyrlabs.com/buy-credits
• human signup form: https://valkyrlabs.com/funnel/white-paper
• scripts/graymatter_api.sh prints both links on INSUFFICIENT_FUNDS and attempts a popup prompt on macOS/Windows
• optional overrides: VALKYR_BUY_CREDITS_URL, VALKYR_HUMAN_SIGNUP_URL

Local fallback

Use local files only as backup, typically:

• memory/YYYY-MM-DD.md
• MEMORY.md
• memory/graymatter-fallback.json

GrayMatter remains the primary system of record whenever available.

Installability standard

For this skill to count as installable and immediately usable, a fresh user should be able to:

1. install the skill
2. authenticate with scripts/gm-login or env vars
3. run scripts/gm-install-check
4. run scripts/gm-smoke
5. run scripts/gm-register-agent
6. run scripts/gm-openapi-sync
7. immediately query memory, write memory, inspect graph state, and inspect live business objects

If any of those fail, the install is not complete.