Service and Agent Node Documentation

SilverAspen operates Service Nodes and Agent Nodes inside the SilverAspen ecosystem.

These nodes are first-class network participants. They exist on the same network level as services and agents operated by third parties building on top of the ecosystem.

SilverAspen-operated nodes provide trusted infrastructure, public services, workflow interfaces, advisory agents, and orchestration capabilities for the ecosystem.

Draft interface notice

The interfaces, endpoint examples, DID service entries, capability names, permission scopes, integration patterns, and example payload concepts shown in this documentation are still in draft. They define the current implementation direction, but may change as the SilverAspen network architecture, service discovery model, and protocol interfaces mature.

1. Naming Principles

Each SilverAspen node has four names:

• Display name
• Network node name
• Infrastructure domain
• Node type

The naming convention keeps SilverAspen-operated nodes:

• Short and easy to identify
• Clear in purpose
• Easy to use in infrastructure
• Easy to distinguish from third-party nodes
• Suitable for DID service discovery, domain routing, logs, permissions, and documentation

2. Display Name

The display name is the human-readable name used in documentation, dashboards, admin panels, and public-facing material.

Format:

SilverAspen [Capability]

Examples:

SilverAspen Invite
SilverAspen Member
SilverAspen Funds
SilverAspen Backup
SilverAspen Screen
SilverAspen Schedule
SilverAspen Fit
SilverAspen Interview
SilverAspen ATS

3. Network Node Name

The network node name is the technical name used in service registries, DID service entries, routing, logging, permission scopes, and network policies.

Format:

sa.[node-type].[capability]

Where:

sa          = SilverAspen
service     = deterministic infrastructure service
agent       = orchestration, negotiation, advisory, or workflow agent
capability  = short capability name

Examples:

sa.service.invite
sa.service.member
sa.agent.funds
sa.service.backup
sa.service.screen
sa.agent.schedule
sa.agent.fit
sa.agent.interview
sa.service.ats

4. Infrastructure Domain

The infrastructure domain is the public network domain for the node.

Format:

[capability].silveraspen.network

Examples:

invite.silveraspen.network
member.silveraspen.network
funds.silveraspen.network
backup.silveraspen.network
screen.silveraspen.network
schedule.silveraspen.network
fit.silveraspen.network
interview.silveraspen.network
ats.silveraspen.network

The domain describes the capability, not the current implementation, provider, or blockchain dependency.

For example, the fund orchestration node uses:

funds.silveraspen.network

It does not use:

cardano-funds.silveraspen.network

The public capability is fund orchestration. Cardano Layer 2 is an execution environment used by the node, not the identity of the node.

5. Node Types

Each node is classified as either:

Service

or:

Agent

5.1 Service Node

A Service Node provides stable infrastructure and exposes deterministic interfaces.

A service usually:

• Exposes APIs
• Stores or validates data
• Serves schemas, templates, stats, records, or integration mappings
• Manages stateful workflows
• Executes requests based on explicit input
• Supports applications, agents, and other services
• Does not independently initiate broad external workflows without a request, consent record, or policy trigger

SilverAspen Service Nodes include:

SilverAspen Invite
SilverAspen Member
SilverAspen Stats
SilverAspen Backup
SilverAspen Sync
SilverAspen Screen
SilverAspen Templates
SilverAspen Schemas
SilverAspen ATS

5.2 Agent Node

An Agent Node performs higher-level orchestration, negotiation, advisory workflows, or workflow preparation across people, services, organizations, candidates, teams, or external systems.

An agent usually:

• Initiates workflows
• Routes work across multiple services
• Coordinates third-party providers
• Starts blockchain workflows
• Negotiates between participants
• Advises human decision-makers
• Prepares structured workflow artifacts
• Makes workflow recommendations based on policy, state, eligibility, or context
• Acts on behalf of a person, organization, fund, or ecosystem process

SilverAspen Agent Nodes include:

SilverAspen Funds
SilverAspen Verify
SilverAspen Schedule
SilverAspen Fit
SilverAspen Interview

6. Naming Rules

SilverAspen node names describe network capabilities, not internal implementation modules.

The following names are not used as public node names:

Membership Handler
Fund Manager
Stats API
KYC Handler
Background Check Processor
Credential Template Manager
Schema Provider API
ATS Connector
Interview Helper Bot
Fit Scoring Engine

The public capability names are:

Invite
Member
Funds
Stats
Backup
Sync
Verify
Screen
Templates
Schemas
Schedule
Fit
Interview
ATS

7. SilverAspen Node Catalog

8. Detailed Node Documentation

8.1 SilverAspen Invite

Display Name: SilverAspen Invite
Node Type: Service
Network Node Name: sa.service.invite
Domain: invite.silveraspen.network

SilverAspen Invite is the invitation service for the SilverAspen ecosystem.

It manages invitation creation, routing, lifecycle state, acceptance, rejection, expiration, cancellation, and revocation.

The Invite service supports invitations between people, organizations, agents, service nodes, circles, grants, jobs, mentors, learning programs, and other network participants.

SilverAspen Invite is not a simple notification service. It is a network-level service that manages invitation context, target eligibility, sender permissions, relationship type, and invitation status.

Primary responsibilities:

• Create invitations
• Route invitations to the correct network participant
• Validate invitation permissions
• Attach context to invitations
• Track invitation lifecycle state
• Support invite-to-circle workflows
• Support invite-to-grant workflows
• Support invite-to-job workflows
• Support invite-to-mentor workflows
• Support invite-to-service workflows
• Support third-party invitation issuers

Example invitation states:

draft
issued
pending
accepted
rejected
expired
cancelled
revoked

Draft capabilities:

invitation.create
invitation.route
invitation.accept
invitation.reject
invitation.cancel
invitation.revoke
invitation.expire
invitation.status.read

Domain:

invite.silveraspen.network

8.2 SilverAspen Member

Display Name: SilverAspen Member
Node Type: Service
Network Node Name: sa.service.member
Domain: member.silveraspen.network

SilverAspen Member manages SilverAspen ecosystem memberships.

It creates, updates, validates, and manages membership state for people, organizations, agents, and service operators that become members of the SilverAspen ecosystem.

The Member service manages the membership relationship between an identity and the SilverAspen ecosystem. It is not the identity authority for the network.

A person, organization, agent, or service node owns its own identity. SilverAspen Member manages whether that identity has a valid SilverAspen membership and what entitlements that membership provides.

Primary responsibilities:

• Create new SilverAspen memberships
• Manage membership status
• Manage membership renewal
• Manage membership suspension
• Manage membership revocation
• Link memberships to network type
• Link memberships to service access
• Issue or trigger membership credentials
• Validate membership-based access rights
• Support different membership classes

Example membership states:

pending
active
suspended
expired
revoked

Draft capabilities:

membership.create
membership.read
membership.update
membership.suspend
membership.revoke
membership.renew
membership.entitlements.read
membership.credential.issue

Domain:

member.silveraspen.network

8.3 SilverAspen Funds

Display Name: SilverAspen Funds
Node Type: Agent
Network Node Name: sa.agent.funds
Domain: funds.silveraspen.network

SilverAspen Funds coordinates grant funding, learning and development budgets, fund allocation rules, spending conditions, and fund lifecycle events.

The Funds agent connects off-chain human-capital goals to on-chain fund execution. It can initiate workflows on a Cardano Layer 2 environment while keeping the network capability name chain-neutral.

SilverAspen Funds orchestrates how funds are allocated, reserved, released, paused, recycled, or expired based on purpose, eligibility, progress, policy, and funding conditions.

The public name is Funds, not Fund Manager, because the node is a protocol-level orchestration agent and should not be confused with a regulated financial manager.

Primary responsibilities:

• Set up grant funding pools
• Manage learning and development budgets
• Define fund allocation rules
• Trigger Cardano Layer 2 workflows
• Connect grants to user goals
• Connect funding to learning progress
• Release funds based on milestones
• Pause unused allocations
• Decay unused allocations
• Recycle unused funds
• Track fund lifecycle state
• Coordinate with learning providers
• Coordinate with grant sponsors
• Support auditable fund execution

Example fund states:

draft
active
allocated
reserved
released
paused
expired
recycled
closed

Draft capabilities:

fund.create
fund.allocate
fund.reserve
fund.release
fund.pause
fund.expire
fund.recycle
fund.status.read
grant.create
grant.assign
grant.progress.evaluate
cardano.workflow.initiate

Domain:

funds.silveraspen.network

8.4 SilverAspen Stats

Display Name: SilverAspen Stats
Node Type: Service
Network Node Name: sa.service.stats
Domain: stats.silveraspen.network

SilverAspen Stats collects operational and usage statistics from SilverAspen services and exposes normalized metrics to public-facing interfaces, dashboards, explorers, reporting systems, and ecosystem analytics tools.

SilverAspen Stats provides aggregated and privacy-safe statistics. It does not expose raw personal vault data, private user records, sensitive identity data, or confidential organization-level information unless the relevant access model explicitly permits it.

Primary responsibilities:

• Collect service-level statistics
• Aggregate ecosystem metrics
• Serve public network statistics
• Serve operational dashboards
• Normalize metrics across services
• Support usage reporting
• Support grant reporting
• Support service health reporting
• Provide anonymized and privacy-safe analytics

Example metrics:

active_memberships
active_grants
issued_invitations
accepted_invitations
active_service_nodes
active_agent_nodes
credential_templates_available
schemas_available
backup_subscriptions_active
sync_sessions_completed

Draft capabilities:

stats.collect
stats.aggregate
stats.public.read
stats.service.read
stats.health.read
stats.report.generate

Domain:

stats.silveraspen.network

8.5 SilverAspen Backup

Display Name: SilverAspen Backup
Node Type: Service
Network Node Name: sa.service.backup
Domain: backup.silveraspen.network

SilverAspen Backup provides encrypted backup storage for user vaults.

Users can subscribe to the Backup service to back up their full vault, including encrypted vault contents, KMS-related backup material, vault metadata, device recovery data, and backup manifests.

All data is encrypted before it is sent to SilverAspen Backup. The Backup service does not have access to plaintext vault contents, plaintext private keys, plaintext recovery material, or unencrypted personal data.

The service supports device recovery and restoration of a vault to a new or replacement device.

Primary responsibilities:

• Store encrypted vault backups
• Store encrypted vault metadata
• Store encrypted KMS-related backup material
• Store backup manifests
• Support device recovery
• Support backup versioning
• Support backup integrity checks
• Support backup deletion
• Support subscription-based backup access
• Support disaster recovery workflows

Security requirements:

• Client-side encryption before upload
• No plaintext vault access
• No plaintext private key access
• No plaintext recovery material access
• Strong backup integrity validation
• Explicit user consent for restore
• Recovery authorization controls

Draft capabilities:

backup.create
backup.read
backup.restore
backup.delete
backup.verify
backup.version.list
backup.subscription.read

Domain:

backup.silveraspen.network

8.6 SilverAspen Sync

Display Name: SilverAspen Sync
Node Type: Service
Network Node Name: sa.service.sync
Domain: sync.silveraspen.network

SilverAspen Sync keeps multiple user devices synchronized.

It supports synchronization between existing trusted devices and helps onboard a new device using an already trusted device as the trust anchor.

Sync and Backup are separate services.

Backup is used for recovery, encrypted storage, and restoring a vault.

Sync is used to keep active trusted devices aligned and to support trusted-device handoff.

Primary responsibilities:

• Synchronize vault state across trusted devices
• Support new device onboarding
• Support trusted-device handoff
• Manage device sync sessions
• Track device sync state
• Resolve sync conflicts
• Support encrypted sync payloads
• Support device revocation
• Support device replacement workflows
• Support multi-device account continuity

Example device states:

pending
trusted
active
stale
revoked
replaced

Draft capabilities:

sync.session.create
sync.session.accept
sync.device.register
sync.device.revoke
sync.state.push
sync.state.pull
sync.conflict.resolve
sync.onboarding.initiate

Domain:

sync.silveraspen.network

8.7 SilverAspen Verify

Display Name: SilverAspen Verify
Node Type: Agent
Network Node Name: sa.agent.verify
Domain: verify.silveraspen.network

SilverAspen Verify initiates and coordinates KYC and identity verification workflows across one or more verification providers.

SilverAspen Verify acts as a verification broker. It is not itself the KYC provider.

The Verify agent selects providers, initiates verification requests, normalizes provider responses, tracks workflow state, and can trigger credential issuance after verification is completed.

The public name is Verify, not KYC, because the node supports a broader verification scope than KYC alone.

Supported and future verification workflows include:

• Person verification
• Organization verification
• Residency verification
• Student verification
• Employment verification
• Age verification
• Role verification
• Professional license verification

Primary responsibilities:

• Initiate KYC workflows
• Route verification requests to providers
• Support multiple KYC providers
• Normalize provider responses
• Track verification state
• Trigger credential issuance
• Support verification renewal
• Support verification revocation
• Support organization verification
• Support reusable verification workflows

Example verification states:

requested
in_progress
requires_action
verified
failed
expired
revoked

Draft capabilities:

verification.create
verification.provider.select
verification.status.read
verification.result.normalize
verification.credential.issue
verification.revoke
kyc.workflow.initiate

Domain:

verify.silveraspen.network

8.8 SilverAspen Screen

Display Name: SilverAspen Screen
Node Type: Service
Network Node Name: sa.service.screen
Domain: screen.silveraspen.network

SilverAspen Screen provides background screening workflow services.

It supports OSINT-based checks, third-party screening provider workflows, automated data collection, and human investigation handoff where deeper review is required.

SilverAspen Screen is a sensitive service. It manages screening requests, consent records, workflow state, provider routing, reviewed findings, final attestations, and audit trails.

It separates automated data collection, human-reviewed findings, final screening outcomes, and consent records.

SilverAspen Screen must not be designed as an uncontrolled scraping tool. That would create legal, ethical, and ecosystem trust problems.

Primary responsibilities:

• Create background screening requests
• Manage consent-required screening workflows
• Collect OSINT-based signals where permitted
• Route requests to screening providers
• Coordinate human investigation handoff
• Track screening workflow state
• Separate raw findings from reviewed conclusions
• Support screening attestations
• Support screening renewal
• Support screening revocation
• Maintain audit logs

Example screening states:

requested
consent_required
collecting
under_review
completed
failed
expired
revoked

Draft capabilities:

screening.create
screening.consent.request
screening.osint.collect
screening.provider.route
screening.human_review.request
screening.status.read
screening.attestation.issue
screening.revoke

Domain:

screen.silveraspen.network

8.9 SilverAspen Templates

Display Name: SilverAspen Templates
Node Type: Service
Network Node Name: sa.service.templates
Domain: templates.silveraspen.network

SilverAspen Templates provides reusable credential templates and a template builder.

Templates define how credentials are structured, displayed, requested, issued, and reused across the SilverAspen ecosystem.

The service provides standard templates maintained by SilverAspen and tools for creating custom templates.

Templates and schemas are separate concepts.

A schema defines data structure and validation.

A template defines how a credential or data object is composed, configured, displayed, requested, and used in a workflow.

Primary responsibilities:

• Provide standard credential templates
• Provide a template builder
• Manage template versions
• Support custom templates
• Link templates to schemas
• Define required and optional fields
• Define display rules
• Define issuance flow hints
• Define credential request forms
• Support template discovery

Example template types:

student_card
membership_card
grant_award
learning_goal
skill_attestation
employment_attestation
organization_membership
mentor_assignment
circle_membership

Draft capabilities:

template.create
template.read
template.update
template.publish
template.version.read
template.schema.link
template.builder.open
template.discovery.search

Domain:

templates.silveraspen.network

8.10 SilverAspen Schemas

Display Name: SilverAspen Schemas
Node Type: Service
Network Node Name: sa.service.schemas
Domain: schemas.silveraspen.network

SilverAspen Schemas provides canonical schemas, extended schemas, validation rules, and schema versioning for the SilverAspen ecosystem.

SilverAspen Schemas is critical infrastructure. Schema drift breaks interoperability across credentials, templates, grants, memberships, agents, services, and applications.

The Schemas service provides standard schemas maintained by SilverAspen, extended schemas based on external standards, and validation endpoints or schema discovery mechanisms for applications, agents, services, and credential issuers.

Primary responsibilities:

• Provide canonical SilverAspen schemas
• Provide extended schemas
• Provide schema versioning
• Provide schema discovery
• Provide validation rules
• Support schema compatibility checks
• Link schemas to credential templates
• Support schema deprecation
• Support schema migration guidance
• Support ecosystem-wide interoperability

Example schema categories:

person
organization
agent
service_node
membership
credential
grant
fund
skill
goal
learning_activity
employment_record
circle
invitation
verification
screening

Draft capabilities:

schema.create
schema.read
schema.publish
schema.version.read
schema.validate
schema.compatibility.check
schema.deprecate
schema.discovery.search

Domain:

schemas.silveraspen.network

8.11 SilverAspen Schedule

Display Name: SilverAspen Schedule
Node Type: Agent
Network Node Name: sa.agent.schedule
Domain: schedule.silveraspen.network

SilverAspen Schedule is the scheduling negotiation agent for the SilverAspen ecosystem.

It helps two or more Person Nodes negotiate a suitable time to meet. The Schedule agent can communicate back and forth between participants, compare availability windows, apply meeting preferences, propose time slots, handle counterproposals, and confirm the selected meeting time.

SilverAspen Schedule is not just a calendar API wrapper. It acts as a negotiation agent that helps participants reach agreement while respecting user preferences, calendar privacy, availability constraints, time zones, working hours, and consent boundaries.

Primary responsibilities:

• Negotiate meeting times between Person Nodes
• Compare availability windows
• Manage scheduling proposals
• Manage counterproposals
• Respect time zones and working hours
• Respect user-defined scheduling preferences
• Prevent unnecessary exposure of full calendar data
• Confirm accepted meeting times
• Support rescheduling workflows
• Support cancellation workflows
• Support scheduling between people, teams, mentors, candidates, hiring managers, and service operators

Example scheduling states:

requested
availability_requested
proposed
counter_proposed
accepted
declined
rescheduled
cancelled
expired

Draft capabilities:

schedule.request.create
schedule.availability.request
schedule.proposal.create
schedule.proposal.counter
schedule.proposal.accept
schedule.proposal.decline
schedule.meeting.confirm
schedule.meeting.reschedule
schedule.meeting.cancel
schedule.status.read

Domain:

schedule.silveraspen.network

8.12 SilverAspen Fit

Display Name: SilverAspen Fit
Node Type: Agent
Network Node Name: sa.agent.fit
Domain: fit.silveraspen.network

SilverAspen Fit is the role, candidate, and team fit advisory agent for the SilverAspen ecosystem.

It helps a manager, hiring lead, or authorized team member understand how an active candidate may fit a role, a team, and a broader organizational context.

SilverAspen Fit can analyze the required capabilities for a job role, compare them against a candidate profile, and include the capabilities, gaps, dynamics, strengths, risks, and development potential of the existing team.

The Fit agent is designed as a sparring partner for human decision-makers. It does not make hiring decisions. It does not produce automatic accept or reject outcomes. It supports structured analysis, reflective questioning, and better human judgment.

A perfect role match is not always the best hire. A candidate with a lower direct role match may create stronger team outcomes if they add missing capabilities, improve team dynamics, bring rare traits, or reveal that the original role definition was too narrow.

SilverAspen Fit helps expose those blind spots.

Primary responsibilities:

• Analyze role capability requirements
• Analyze candidate capabilities against the role
• Compare candidate capabilities with current team capabilities
• Identify capability gaps
• Identify team-level strengths and weaknesses
• Identify candidate development areas
• Identify potential danger zones
• Identify potential upside zones
• Support EQ-related analysis where validated data exists
• Support team dynamics analysis
• Support role-definition review
• Highlight where the role may have been defined too narrowly
• Help managers reason through tradeoffs
• Produce advisory fit insights for human review

The Fit agent must not be used as an automated hiring decision engine.

Primary constraints:

• Human decision-making remains required
• Candidate consent and access controls are required
• Sensitive traits require strict governance
• Assessment data must be provenance-aware
• EQ or psychometric inputs must be treated carefully
• Output must explain reasoning and uncertainty
• The agent must surface risks without creating discriminatory conclusions
• The agent must support auditability

Example fit dimensions:

role_capability_fit
team_capability_complement
growth_potential
team_dynamic_risk
team_dynamic_upside
leadership_style_fit
communication_style_fit
learning_curve
critical_gap_risk
unique_capability_value
role_definition_risk

Example fit states:

draft
context_requested
candidate_profile_loaded
team_context_loaded
analysis_in_progress
review_ready
reviewed
archived
revoked

Draft capabilities:

fit.analysis.create
fit.role.evaluate
fit.team.evaluate
fit.candidate.evaluate
fit.gap.identify
fit.risk.identify
fit.potential.identify
fit.role_definition.review
fit.team_dynamic.evaluate
fit.eq_context.evaluate
fit.report.generate
fit.status.read

Domain:

fit.silveraspen.network

8.13 SilverAspen Interview

Display Name: SilverAspen Interview
Node Type: Agent
Network Node Name: sa.agent.interview
Domain: interview.silveraspen.network

SilverAspen Interview is the dynamic interview preparation and collaboration agent for the SilverAspen ecosystem.

It creates an interview helper using context from the team, role definition, candidate profile, candidate traits, role requirements, and previous fit analysis where available.

The Interview agent helps hiring teams identify which areas should be explored with a candidate. It can rank topics, generate interview prompts, suggest follow-up questions, highlight areas of uncertainty, and help structure the interview around role fit, team fit, capability gaps, development zones, and unique candidate potential.

SilverAspen Interview also supports controlled sharing of candidate context among team members involved in the hiring process.

The Interview agent does not replace the interviewer. It improves preparation, consistency, collaboration, and traceability.

Primary responsibilities:

• Create dynamic interview guides
• Use role definition context
• Use team context
• Use candidate profile context
• Use candidate traits and capability signals
• Rank areas to explore with the candidate
• Generate interview questions
• Generate follow-up prompts
• Highlight uncertainty areas
• Highlight candidate strengths to validate
• Highlight potential risk zones to explore
• Highlight potential development zones
• Store interview preparation artifacts
• Support structured note-taking
• Support team-based candidate review
• Share candidate context with authorized hiring team members
• Track interview feedback and review state

Primary constraints:

• Candidate data sharing requires authorization
• Interview artifacts require access control
• Sensitive traits require governance
• Interview prompts must avoid discriminatory questions
• The agent must not make automatic hiring decisions
• Stored interview records must be auditable
• Candidate-facing and internal notes must be clearly separated

Example interview dimensions:

technical_capability
role_specific_experience
learning_potential
team_collaboration
communication_style
leadership_style
culture_add
risk_area
development_area
motivation
adaptability
unique_strength

Example interview states:

draft
context_loaded
guide_generated
shared_with_team
interview_scheduled
interview_in_progress
notes_added
feedback_requested
feedback_completed
review_ready
archived
revoked

Draft capabilities:

interview.guide.create
interview.topic.rank
interview.question.generate
interview.followup.generate
interview.context.load
interview.candidate.share
interview.team.share
interview.notes.create
interview.feedback.request
interview.feedback.submit
interview.report.generate
interview.status.read

Domain:

interview.silveraspen.network

8.14 SilverAspen ATS

Display Name: SilverAspen ATS
Node Type: Service
Network Node Name: sa.service.ats
Domain: ats.silveraspen.network

SilverAspen ATS is the applicant tracking system broker service for the SilverAspen ecosystem.

It converts candidate, role, interview, screening, verification, and fit-related data into formats that can be sent to external ATS platforms such as Workday, Greenhouse, Lever, and other recruiting systems.

SilverAspen ATS acts as an integration service between SilverAspen network data and external applicant tracking systems.

It may use MCP-based connectors where appropriate.

SilverAspen ATS is a service, not an agent, because its primary responsibility is deterministic transformation, mapping, permission-aware export, and external system integration.

Primary responsibilities:

• Convert candidate profile data into ATS-compatible formats
• Convert role and job data into ATS-compatible formats
• Send candidate data to external ATS systems
• Update ATS candidate records
• Sync interview artifacts where permitted
• Sync screening status where permitted
• Sync verification status where permitted
• Sync fit advisory summaries where permitted
• Normalize ATS provider differences
• Manage provider-specific mappings
• Support Workday integrations
• Support Greenhouse integrations
• Support Lever integrations
• Support MCP-based connector workflows
• Track export and sync status
• Maintain audit logs for data transfers

Primary constraints:

• Candidate data export requires authorization
• External ATS transfer requires explicit policy control
• Sensitive data must not be exported by default
• Provider-specific mappings must be versioned
• Failed exports must be traceable
• Data minimization must be applied
• Audit logs are required for every export
• MCP connectors must be permission-scoped

Example ATS providers:

workday
greenhouse
lever
ashby
smartrecruiters
teamtailor
recruitee
custom_mcp_connector

Example ATS states:

draft
mapping_required
ready_to_export
exporting
exported
syncing
synced
failed
revoked

Draft capabilities:

ats.mapping.create
ats.mapping.read
ats.candidate.convert
ats.candidate.export
ats.candidate.sync
ats.role.convert
ats.role.export
ats.interview.sync
ats.screening.sync
ats.verification.sync
ats.fit_summary.sync
ats.provider.connect
ats.provider.disconnect
ats.mcp.invoke
ats.status.read

Domain:

ats.silveraspen.network

9. Canonical Short Names

The following names are used consistently across documentation, infrastructure, DID service entries, logs, permission scopes, and service discovery.

10. Public Discovery Document

Each SilverAspen node exposes a public metadata document at:

https://[capability].silveraspen.network/.well-known/silveraspen-node.json

Draft interface notice

The structure of silveraspen-node.json is still in draft. Field names, endpoint names, capability declarations, and versioning rules may change before the interface is finalized.

Example for SilverAspen Invite:

{
  "name": "SilverAspen Invite",
  "nodeName": "sa.service.invite",
  "type": "Service",
  "domain": "invite.silveraspen.network",
  "operator": "SilverAspen",
  "ecosystem": "SilverAspen",
  "version": "1.0.0",
  "capabilities": [
    "invitation.create",
    "invitation.route",
    "invitation.accept",
    "invitation.reject",
    "invitation.cancel",
    "invitation.revoke",
    "invitation.expire",
    "invitation.status.read"
  ],
  "serviceEndpoint": "https://invite.silveraspen.network",
  "statusEndpoint": "https://invite.silveraspen.network/status",
  "docsEndpoint": "https://invite.silveraspen.network/docs"
}

Example for SilverAspen Fit:

{
  "name": "SilverAspen Fit",
  "nodeName": "sa.agent.fit",
  "type": "Agent",
  "domain": "fit.silveraspen.network",
  "operator": "SilverAspen",
  "ecosystem": "SilverAspen",
  "version": "1.0.0",
  "capabilities": [
    "fit.analysis.create",
    "fit.role.evaluate",
    "fit.team.evaluate",
    "fit.candidate.evaluate",
    "fit.gap.identify",
    "fit.risk.identify",
    "fit.potential.identify",
    "fit.role_definition.review",
    "fit.team_dynamic.evaluate",
    "fit.eq_context.evaluate",
    "fit.report.generate",
    "fit.status.read"
  ],
  "serviceEndpoint": "https://fit.silveraspen.network",
  "statusEndpoint": "https://fit.silveraspen.network/status",
  "docsEndpoint": "https://fit.silveraspen.network/docs"
}

Example for SilverAspen ATS:

{
  "name": "SilverAspen ATS",
  "nodeName": "sa.service.ats",
  "type": "Service",
  "domain": "ats.silveraspen.network",
  "operator": "SilverAspen",
  "ecosystem": "SilverAspen",
  "version": "1.0.0",
  "capabilities": [
    "ats.mapping.create",
    "ats.mapping.read",
    "ats.candidate.convert",
    "ats.candidate.export",
    "ats.candidate.sync",
    "ats.role.convert",
    "ats.role.export",
    "ats.interview.sync",
    "ats.screening.sync",
    "ats.verification.sync",
    "ats.fit_summary.sync",
    "ats.provider.connect",
    "ats.provider.disconnect",
    "ats.mcp.invoke",
    "ats.status.read"
  ],
  "serviceEndpoint": "https://ats.silveraspen.network",
  "statusEndpoint": "https://ats.silveraspen.network/status",
  "docsEndpoint": "https://ats.silveraspen.network/docs"
}

11. DID Service Entry Pattern

If a SilverAspen node is represented in a DID Document, the DID service entry uses the same canonical naming convention.

Draft interface notice

The DID service entry structure shown below is still in draft. The type, metadata, accept, and capability fields may change as DIDComm, service discovery, and SilverAspen node metadata conventions mature.

Example for SilverAspen Invite:

{
  "id": "#sa-service-invite",
  "type": "SilverAspenService",
  "serviceEndpoint": "https://invite.silveraspen.network",
  "routingKeys": [],
  "accept": [
    "didcomm/v2"
  ],
  "metadata": {
    "name": "SilverAspen Invite",
    "nodeName": "sa.service.invite",
    "capabilities": [
      "invitation.create",
      "invitation.route",
      "invitation.accept",
      "invitation.reject",
      "invitation.cancel",
      "invitation.revoke"
    ]
  }
}

Example for SilverAspen Backup:

{
  "id": "#sa-service-backup",
  "type": "SilverAspenService",
  "serviceEndpoint": "https://backup.silveraspen.network",
  "metadata": {
    "name": "SilverAspen Backup",
    "nodeName": "sa.service.backup",
    "capabilities": [
      "backup.create",
      "backup.read",
      "backup.restore",
      "backup.delete",
      "backup.verify"
    ],
    "encryptionRequired": true,
    "plaintextAccess": false
  }
}

Example for SilverAspen Funds:

{
  "id": "#sa-agent-funds",
  "type": "SilverAspenAgentService",
  "serviceEndpoint": "https://funds.silveraspen.network",
  "metadata": {
    "name": "SilverAspen Funds",
    "nodeName": "sa.agent.funds",
    "capabilities": [
      "fund.create",
      "fund.allocate",
      "fund.reserve",
      "fund.release",
      "fund.recycle",
      "grant.create",
      "grant.assign",
      "grant.progress.evaluate",
      "cardano.workflow.initiate"
    ]
  }
}

Example for SilverAspen Schedule:

{
  "id": "#sa-agent-schedule",
  "type": "SilverAspenAgentService",
  "serviceEndpoint": "https://schedule.silveraspen.network",
  "metadata": {
    "name": "SilverAspen Schedule",
    "nodeName": "sa.agent.schedule",
    "capabilities": [
      "schedule.request.create",
      "schedule.availability.request",
      "schedule.proposal.create",
      "schedule.proposal.counter",
      "schedule.proposal.accept",
      "schedule.meeting.confirm"
    ]
  }
}

Example for SilverAspen ATS:

{
  "id": "#sa-service-ats",
  "type": "SilverAspenService",
  "serviceEndpoint": "https://ats.silveraspen.network",
  "metadata": {
    "name": "SilverAspen ATS",
    "nodeName": "sa.service.ats",
    "capabilities": [
      "ats.mapping.create",
      "ats.candidate.convert",
      "ats.candidate.export",
      "ats.provider.connect",
      "ats.mcp.invoke"
    ]
  }
}

12. Capability Naming Pattern

Capabilities follow this pattern:

[domain-object].[action]

Examples:

invitation.create
invitation.route
membership.create
membership.revoke
fund.allocate
fund.release
backup.restore
sync.device.register
verification.create
screening.osint.collect
template.publish
schema.validate
schedule.proposal.create
fit.analysis.create
interview.guide.create
ats.candidate.export

Vague capability names are not used.

Do not use:

process
handle
manage
run
execute
doCheck
submitData

These names are not precise enough for permissions, logs, auditing, and developer experience.

13. Permission Scope Pattern

Permission scopes follow the same structure as capabilities.

Format:

sa:[node-type]:[capability]:[action]

Examples:

sa:service:invite:create
sa:service:invite:route
sa:service:member:read
sa:service:member:revoke
sa:agent:funds:allocate
sa:agent:funds:release
sa:service:backup:restore
sa:service:sync:device-register
sa:agent:verify:create
sa:service:screen:human-review-request
sa:service:templates:publish
sa:service:schemas:validate
sa:agent:schedule:proposal-create
sa:agent:schedule:meeting-confirm
sa:agent:fit:analysis-create
sa:agent:fit:team-dynamic-evaluate
sa:agent:interview:guide-create
sa:agent:interview:candidate-share
sa:service:ats:candidate-export
sa:service:ats:mcp-invoke

Permission scopes must remain explicit and predictable.

14. Final Node List

SilverAspen Invite      sa.service.invite      invite.silveraspen.network
SilverAspen Member      sa.service.member      member.silveraspen.network
SilverAspen Funds       sa.agent.funds         funds.silveraspen.network
SilverAspen Stats       sa.service.stats       stats.silveraspen.network
SilverAspen Backup      sa.service.backup      backup.silveraspen.network
SilverAspen Sync        sa.service.sync        sync.silveraspen.network
SilverAspen Verify      sa.agent.verify        verify.silveraspen.network
SilverAspen Screen      sa.service.screen      screen.silveraspen.network
SilverAspen Templates   sa.service.templates   templates.silveraspen.network
SilverAspen Schemas     sa.service.schemas     schemas.silveraspen.network
SilverAspen Schedule    sa.agent.schedule      schedule.silveraspen.network
SilverAspen Fit         sa.agent.fit           fit.silveraspen.network
SilverAspen Interview   sa.agent.interview     interview.silveraspen.network
SilverAspen ATS         sa.service.ats         ats.silveraspen.network

This naming layer defines SilverAspen-operated services and agents as visible, interoperable, and discoverable network participants while leaving room for third-party nodes to participate in the same ecosystem.