Skip to main content
The Scoutica Protocol is built on six foundational pillars that together define how Skill Cards are created, shared, trusted, extended, protected, and monetized.
How Skill Cards are created. Four methods are supported:
MethodCommandDescription
AI scanscoutica scanAuto-generate from documents via local AI
Interactivescoutica initStep-by-step wizard
ManualCreate files directlyFor developers who prefer full control
AI pastescoutica scan --clipboardCopy prompt, paste into any AI assistant
Each method produces the same four canonical files: profile.json, rules.yaml, evidence.json, and scoutica.json.Schema hierarchy:
  • profile.json links to Skills Taxonomy, Experience Records, and Language Proficiencies
  • rules.yaml defines Engagement Rules, Compensation Floor, and Auto-Reject Criteria
  • evidence.json links to GitHub repos, certifications, and portfolio entries
How cards are discovered and accessed.Cards are published to a GitHub repository and made discoverable through four mechanisms:
  1. scoutica.json — well-known file at the repo root; the primary entry point for any consumer
  2. Registry index — centralized JSON index (GitHub-based) for search queries
  3. GitHub Topics — tag repos with scoutica-card for passive discovery
  4. Direct URL — scoutica resolve <url> fetches and displays any card by URL
# Resolve a card from a GitHub URL
scoutica resolve https://github.com/user/my-card
How trust is established. The protocol defines five trust levels:
LevelNameTrust MultiplierDescription
0Self-Asserted0.0×Candidate claims it; no external verification
1URL-Verified0.5×Evidence URLs are reachable
2Peer-Endorsed1.0×Other cards vouch for skills
3Platform-Verified1.5×CI/CD: commits and contributions verified
4Blockchain-Verified2.0×Soulbound Token endorsement
Levels 0–3 are available today. Level 4 (blockchain verification) is on the roadmap.
The protocol supports multiple entity types, not just individual humans. This allows AI agents, APIs, robots, and organizations to participate in the same network.
Entity typeDescriptionExample
humanIndividual professionalSoftware engineer
ai_agentAutonomous AI agentCoding assistant
serviceAPI or SaaS productTranslation API
robotPhysical automated systemWarehouse drone
teamGroup of entitiesEngineering squad
organizationCompany or departmentDevOps team
The entity_type field in scoutica.json declares the type of the card owner.
The protocol uses a three-zone data model to give candidates fine-grained control over what is visible and to whom.
ZoneAccessContents
Zone 1Public, freeTitle, seniority, domains, availability
Zone 2Auth requiredFull profile, evidence, experience
Zone 3Candidate approvalEmail, phone, exact salary
Zones are progressive — access to Zone 2 requires authentication, and Zone 3 requires explicit candidate approval for each request.GDPR compliance:
  • Candidate owns all data
  • Right to deletion: delete the repo and the card disappears from the network
  • Right to portability: standard JSON/YAML formats
  • Transparency: candidates see exactly what agents see
Never store Zone 3 data (email, phone, exact salary). These fields are ephemeral and must not be persisted in any cache or database.
Revenue flows in the Scoutica Protocol ecosystem.
ActorRevenue streamAmount
CandidateMicro-fee per Zone 2 access~$0.05
ProtocolCommission on micro-fees10%
VerifierFee for endorsing skillsMarket rate
RegistrySubscription for premium searchTBD
Cost comparison:
ChannelCost per hire
LinkedIn Recruiter~$10,000/year
Recruiting agency15,000–15,000–30,000
Scoutica Protocol~$4
The micropayment layer (~0.05perZone2access)andthe‘0.05 per Zone 2 access) and the `SKILL` token are on the roadmap. See the Roadmap for details.