Marvia-20
Everything extensible, documented and discoverable
Zero core modification: a creator adds capability through the SDK, publishes through the marketplace and never patches the kernel.
coreplatformcreator-sdkextensionsmarketplaceworkspacecommunity
developer-first
A dedicated SDK, CLI and tooling ship with the platform, not after it.
open-core
The kernel is extensible through open, versioned APIs.
extension-first
Every feature is designed as an extension; the core is never modified to add one.
documentation-first
Docs, examples and API references are generated from the manifest and SDK types.
convention-over-configuration
Sensible defaults everywhere, with an explicit override for each.
type-safe
SDKs and manifests are strongly typed; an invalid asset fails at build time.
capability-driven
Features are contributed as capabilities into one registry.
registry-driven
Every asset class resolves through a central, discoverable registry.
marketplace-ready
The full publish lifecycle is available from the first command.
versioned
Semantic versioning applies to the SDK, the manifest and every published asset.
Standards
- — Zero core modification: an extension never patches the kernel.
- — Everything extensible, documented and discoverable.
- — A creator can go from scaffold to published asset without leaving the CLI.
Portal and workspace
A creator surface built on the same shell
Ownership, permissions and audit behave exactly as they do in any other workspace.
Creator portal
- Projects
- Extensions, connectors and blueprints under active development.
- Assets
- Templates, learning packs and knowledge packs owned by the creator.
- Marketplace
- Published listings, versions, channels and revenue tracking.
- Analytics
- Downloads, installs, usage and error rates per asset.
- Documentation
- Auto-generated guides and API references per project.
- Developer profile
- Contributions, ranking, verification state and showcase.
Creator workspace
- Projects
- The working tree for each asset with its manifest and capabilities.
- Sandbox
- Isolated execution against emulators, never against tenant data.
- Marketplace drafts
- Unpublished assets held in the draft channel.
- Publishing
- Validation, preview and submission into the review queue.
- Revenue dashboard
- Earnings, subscriptions and payouts from the monetization engine.
- Documentation
- Local preview of the generated documentation site.
Rules
- — The creator workspace is a workspace like any other: same shell, same permissions, same audit trail.
- — Revenue and analytics are read from the monetization and marketplace engines, never recomputed locally.
- — A creator only ever sees assets they own or are a collaborator on.
Deliverables
Creator portalCreator workspacePublic SDKCLIStarter templatesDocumentation generatorValidation enginePlaygroundTesting frameworkPackaging frameworkPublishing pipelineAnalytics dashboardRevenue dashboardPublic APIsDeveloper documentationArchitecture documentation
Public SDK
Ten packages, one typed surface
The SDK is the only supported integration surface; internal kernel imports are never a contract.
@marvia/sdk-core@marvia/sdk-ui@marvia/sdk-connector@marvia/sdk-marketplace@marvia/sdk-learning@marvia/sdk-ai@marvia/sdk-content@marvia/sdk-report@marvia/sdk-testing@marvia/sdk-cli
- defineExtension(manifest: ExtensionManifest) => Extensionextension
- Declare an extension and everything it contributes.
- defineConnector(config: ConnectorConfig) => Connectorextension
- Declare a provider connector with its auth kind and sync modes.
- defineCapability(capability: Capability) => voidextension
- Register a capability with permissions, credits and risk.
- defineWidget(widget: WidgetConfig) => Widgetui
- Contribute a dashboard widget to a surface.
- defineDashboard(dashboard: DashboardConfig) => Dashboardui
- Compose a schema-driven dashboard from widgets.
- defineContent(content: ContentConfig) => Contentcontent
- Contribute content through the universal content engine.
- defineKnowledge(knowledge: KnowledgeConfig) => Knowledgecontent
- Contribute knowledge objects and their relations.
- defineLesson(lesson: LessonConfig) => Lessoncontent
- Contribute a lesson with practice and validation.
- defineMarketplaceAsset(asset: MarketplaceAsset) => MarketplaceAssetmarketplace
- Describe the listing for a publishable asset.
- definePricing(pricing: PricingModel) => PricingModelmarketplace
- Attach a licence and price to an asset.
- defineAIProvider(provider: AIProviderConfig) => AIProviderai
- Register a provider behind the AI router contract.
Rules
- — The public SDK is the only supported integration surface; internal kernel imports are not a contract.
- — Every define function returns a typed, owner-attributed registry entry.
- — No SDK function reads a secret, mutates a wallet or bypasses approval.
- — SDK versions track the platform version and stay backwards compatible within a major.
Coding standards
- One SDK
- A single unified TypeScript SDK; no per-domain forks.
- One manifest
- One standardised metadata schema for every asset type.
- One runtime
- The same sandboxed execution environment in dev, preview and production.
- One registry
- A central registry for assets, capabilities and schemas.
- Everything documented
- Docs and examples generated from source, never hand-synced.
- Everything reusable
- Modular, composable components with no private forks.
- Everything typed
- Strong TypeScript definitions across SDK, CLI and manifests.
CLI and local development
Scaffold, run, validate, publish
The CLI is a thin client over the same public APIs the portal calls, non-interactive by default so it runs unchanged in CI.
Commands
- $ marvia create extension --name "MyExtension"
- Scaffold an extension from a starter template.
- $ marvia create connector --type "API"
- Scaffold a connector with an auth kind and sync mode.
- $ marvia create blueprint --template "SEO"
- Scaffold a blueprint workflow from a published template.
- $ marvia dev --hot-reload
- Run the local runtime with emulators and hot reload.
- $ marvia test --coverage
- Run the testing framework across all nine suites.
- $ marvia validate --manifest
- Run the validation engine over the manifest and capabilities.
- $ marvia publish --draft
- Package the asset and submit it to the draft channel.
- $ marvia preview --asset-id "123"
- Open a reviewer preview of an unpublished version.
- $ marvia upgrade --extension "my-extension"
- Migrate an asset to a newer SDK or manifest version.
- $ marvia docs generate --api
- Generate the API reference from manifest and SDK types.
- $ marvia docs preview
- Serve the generated documentation site locally.
- — The CLI is a thin client over the same public APIs the portal uses.
- — Every command is non-interactive by default so it runs unchanged in CI.
- — A destructive command requires an explicit confirmation flag.
Starter templates
- SEO extension
- Reads the UWO, emits findings, renders a report section.
- API connector
- OAuth2 or API-key provider adapter with incremental sync.
- Learning pack
- Path, lessons, practice exercises and a credential.
- Knowledge pack
- Knowledge objects with relations and search metadata.
- Dashboard widget
- Permission-scoped widget bound to a schema.
- Content template
- Schema-driven template for the content engine.
- Report template
- Section layout over the fixed report structure.
- AI agent
- Agent with prompts, capabilities and a planning strategy.
- Automation packplanned
- Trigger and action bundles for scheduled workflows.
Emulators
- hot-reload
- Rebuilds and re-registers contributions without restarting the runtime.
- workspace
- A synthetic workspace with roles, permissions and memberships.
- snapshot
- Deterministic snapshot fixtures so pipelines run offline.
- mock-connector
- Recorded provider responses with configurable failures.
- credit
- A fake wallet that reserves and settles without real spend.
- marketplace
- Local listing, install and rollback flows.
- ai
- Scripted model responses and tool calls for reproducible tests.
- — A template scaffolds a valid, publishable asset that passes validation on first run.
- — Emulators never touch tenant data; a sandbox run is isolated by construction.
Validation and testing
Ten checks, nine suites, one result everywhere
A blocking check fails the publish; a non-blocking check becomes a reviewer warning.
Validation engine
- manifestblocking
- The manifest parses and satisfies the current schema version.
- capabilitiesblocking
- Every declared capability resolves and declares cost and risk.
- permissionsblocking
- Permission scopes are least privilege and each one is justified.
- commandsblocking
- Command routing is unambiguous and every command validates its input.
- widgetsblocking
- Widget schemas match the dashboard contract for their surface.
- contentblocking
- Content structures conform to the registered template schema.
- marketplaceblocking
- Listing metadata, media and licence are complete.
- compatibilityblocking
- Declared core and extension version ranges are satisfiable.
- performancewarning
- Benchmarks stay within the declared budget for the asset class.
- securityblocking
- Security policy: no secret access, no unsandboxed code, dependencies scanned.
Test suites
- unit
- Pure logic in isolation.
- integration
- Contributions wired against the kernel registries.
- runtime
- Execution inside the sandbox with real lifecycle events.
- manifest
- Manifest validity across supported schema versions.
- marketplace
- Packaging, install, upgrade and rollback.
- permission
- Denied scopes fail closed with no partial effect.
- compatibility
- Declared version ranges against current and previous kernels.
- snapshot
- Deterministic output against snapshot fixtures.
- ai
- Prompt, plan and tool-call behaviour against scripted providers.
Rules
- — Validation runs identically in the CLI, in CI and in the review queue.
- — A cached validation result is reused only when the asset digest is unchanged.
- — Every validation run is written to the audit trail with its outcome.
Packaging and publishing
Draft → review → publish → rollback
A published version is immutable and content-addressed; a fix is always a new version.
draftvalidatedpreviewedsubmittedin-reviewapprovedpublishedupdatedrolled-backarchived
Packaged asset types
extensionconnectorblueprintknowledge-packlearning-packtemplatebundle
- — A package is content-addressed: the same source always produces the same digest.
- — A published version is immutable; a fix is a new version, never an overwrite.
- — Packaging runs in parallel per artifact and reuses the incremental build cache.
Creator analytics
- downloads-installs
- Downloads and completed installs per version and channel.
- revenue
- One-time sales and recurring subscription revenue.
- ratings
- Ratings and reviews with response state.
- usage-retention
- Active workspaces, runs per install and retention curves.
- compatibility
- Installs failing a declared version range.
- errors
- Runtime error rate by version, with the top failing capability.
- adoption
- Workspace adoption by plan and region.
Revenue streams
- sales
- One-time asset purchases.
- subscriptions
- Recurring access to an asset or pack.
- revenue-share
- Marketplace split settled by the monetization engine.
- extension-packs
- Bundled features sold as one listing.
- learning-packs
- Learning and knowledge packs sold as content.
- blueprint-sales
- Pre-built workflow solutions.
- sponsorshipsplanned
- Community sponsorship of maintained assets.
Community and APIs
Profiles, registries and public endpoints
The ecosystem is discoverable from the outside: registries are searchable and every contract is generated.
Developer ecosystem
- profiles
- Public developer profile with contributions and published assets.
- organizations
- Teams sharing ownership of projects and payouts.
- verified-creators
- Reviewed publishers with an elevated trust badge.
- showcase
- Curated featured assets on the marketplace home.
- ranking
- Contribution ranking derived from adoption, quality and support.
- — AI assistance suggests; a creator always reviews before anything is written or published.
- — Ranking inputs are public and computed from marketplace data, never editorially adjusted in private.
Public APIs
- rest
- Public REST endpoints for assets, versions and analytics.
- webhooks
- Signed event notifications for install, publish and revenue events.
- event-stream
- Real-time stream of marketplace and runtime events.
- openapi
- OpenAPI specification generated from the route contracts.
- sdk-bindings
- TypeScript bindings today, further languages generated from OpenAPI.
- graphqlplanned
- A GraphQL surface over the same resolvers.
Registry explorer
widgetscommandscapabilitiesschemaspatternsconnectorsmarketplace-assetsknowledge-objectslearning-modules
AI assistance
- — Generate boilerplate for a scaffolded asset.
- — Review a manifest against best practice and flag over-broad permissions.
- — Suggest improvements to an extension from its analytics.
- — Auto-generate documentation from manifest and SDK types.
- — Create test cases for declared capabilities.
- — Explain an SDK concept next to the code that uses it.
- — Refactor legacy contributions onto the current SDK version.
- — Estimate credit usage for a capability before publishing.
- — Validate content structures against the registered template schema.
Operations
Events, performance, security and roadmap
The creator platform listens to marketplace and monetization events and owns none of their state.
Consumed events
- asset.published
- Refresh listings and open the analytics baseline for the version.
- asset.installed
- Increment adoption metrics for the creator dashboard.
- extension.error
- Raise the error rate signal and flag the failing capability.
- payment.settled
- Update the revenue dashboard from the monetization ledger.
- review.submitted
- Notify the creator and surface the review in the portal.
Emitted
creator.project.createdcreator.validation.completedcreator.package.builtcreator.asset.submittedcreator.asset.rolled_backcreator.docs.generatedcreator.revenue.updatedcreator.profile.verified
Performance
- — Builds are incremental: only changed components are rebuilt.
- — Hot reload re-registers contributions without a runtime restart.
- — Compilation is lazy; code is generated on demand.
- — Validation results are cached by asset digest.
- — Packaging runs in parallel across artifacts.
Security
- permission-scopes
- Least privilege enforced at load time; an undeclared scope is denied.
- secret-management
- Secrets live in the vault; creator code receives references, never values.
- capability-isolation
- Every capability executes sandboxed with no ambient authority.
- dependency-scanning
- Dependencies are scanned for known vulnerabilities before review.
- marketplace-integrity
- Package digests are verified on install; signatures are the next step.
- audit-logs
- Validation, packaging, publishing and rollback are all audit-trailed.
- — Digital signatures for every published asset.
- — SOC 2 and GDPR compliance documentation for the creator surface.
- — Mandatory penetration testing for privileged asset classes.
Roadmap
- Phase 1
- Core SDK, CLI and the validation engine.
- Phase 2
- Creator portal, creator workspace and marketplace publishing.
- Phase 3
- AI assistance, advanced analytics and community features.
- Phase 4
- Performance optimisation and security hardening.