An operational record
for AI assets

Software has package registries, version numbers, licences, and changelogs. AI assets have almost none of this. A dataset is a folder. A model is a file. An agent is a URL that may or may not still work tomorrow.

This is tolerable inside one team and untenable between organizations. A company licensing a dataset cannot easily establish where it came from, whether it contains personal data, or whether it has changed since they last looked. A company licensing a model cannot tell what it was trained on or whether a checksum still matches. A company licensing an agent has no way to know how it performs beyond the creator's own description of it.

So most AI assets are exchanged privately, on trust, with terms in email threads and usage counted by nobody. That works between two parties who already know each other. It does not scale to a market. Everything in this manual is an answer to one question: what would it take to license an AI asset, of any kind, to a stranger?

Three rules shape almost every design decision that follows. They are worth stating plainly because the rest of the document is, in effect, their consequences.

The formulas in this manual share a small vocabulary. Money is always integer cents, never a floating-point number of dollars, so that a sum of parts always equals the whole. Rounding direction is chosen deliberately and stated wherever it appears.

Every asset moves through the same sequence, whether it is a dataset, a model, or a live agent. Each stage produces the evidence the next stage depends on, verification needs a registered asset, a trust report needs verification, a royalty needs metered delivery.

The one branch is delivery: a dataset or model is streamed through an access-checked gateway, while an agent is proxied call-by-call. Both are metered identically, which is what lets a royalty be computed the same way regardless of asset type. The next section makes the type differences explicit.

Origina is not an agent platform with datasets bolted on. Three asset types are registrable today, Dataset, Model, and Agent, and each is a full citizen of the system. A wider taxonomy (prompt collections, evaluation benchmarks, knowledge bases, workflows, tools, plugins, synthetic datasets) is already modelled so records can be read, even though new ones cannot yet be created.

Datasets and models differ from agents in exactly one structural way: they are files, not live services. That single fact decides how each is delivered, what evidence can be gathered about it, and which parts of the Trust Engine apply. Almost everything else is shared.

A dataset earns integrity and security evidence a live agent structurally cannot, a real SHA-256 checksum, a real secret and PII scan of its contents (Section 9). An agent earns behavioural evidence a file structurally cannot, a real Testbed run against real tasks (Section 10). Verification, versioning, licensing, metering, royalties, and audit apply identically to all three.

The wider catalogue we will offer

Beyond the three registrable types, seven more are already modelled, each with its own file-type allowlist and a verification path in place, waiting only to be switched on. All of them are file-based, so when they open they inherit the entire machinery unchanged: checksum, secret/PII scan, verification, trust scoring, signed-URL delivery, metering, and royalties. Only what each one is differs.

Origina is a domain-driven modular monolith. The system is organised into domains, each owning its business logic end to end. Cross-domain communication happens through published events and narrow public functions, never by reaching into another domain's internals.

Because domains are decoupled through an event bus, a new consumer of an event attaches without the producer knowing it exists. When a licence is granted, the trust, notification, audit, and search domains all react, independently, and without the licensing domain calling any of them.

A Trust Report answers a narrower question than "is this asset good?" It answers "can this asset be trusted?", and it answers it from evidence the platform gathered itself, never from reputation, popularity, or marketing. Datasets, models, and agents are all scored; they simply have different evidence available.

The overall score is simply the sum of what each evidence category earned. There is no hidden weighting beyond the maximum each category can contribute.

The categories and their maxima are fixed and deterministic, identical evidence always produces an identical score. The full table is the real one, lifted from the scoring function:

Sub-scores worth seeing

Two categories are not simple yes/no. Documentation is proportional to how many metadata completeness checks passed:

And for agents only, performance is the most recent Testbed score, rescaled onto its 20-point ceiling. A dataset or model never has this category, its achievable maximum stays 110, not an unreachable 130:

From score to level

The numeric score maps to a named level by fixed thresholds. The label is a reading of the number, not a separate judgement.

Evidence strength, reported, never folded in

A low score can rest on a lot of evidence or almost none, and those are different situations. Evidence strength counts how many of six independent dimensions are present, and is shown beside the score rather than mixed into it.

Verification is where automated checks decide whether an asset has passed. Its outcome is worth 20 of the base 110 points, and, just as importantly, it feeds a full re-computation of the trust score rather than a patch to it.

Nothing edits a score in place. A new outcome produces a new report version, and the old one remains readable, which is what lets a licensee see not just today's trust but its trajectory.

This is where datasets and models carry evidence an agent cannot. Every uploaded file has its contents scanned for two things: leaked secrets and personal data. Both run on the platform itself, real, pattern-based detection, no external service and no account required.

Secrets

The secret scanner matches the well-known formats providers actually issue, AWS key prefixes, GitHub token prefixes, and similar, not guesses. A file containing a live credential is rejected on upload, because publishing someone's leaked key is a harm the platform should refuse to help commit.

Personal data

The PII scanner recognises emails, phone numbers, and government identifiers, US SSNs, credit-card numbers, passports, and national IDs across several countries. Findings are graded into a risk level by the strongest category present: card / SSN / passport are high, national IDs and phone numbers are medium, an email alone is low. That risk level is surfaced as real trust evidence a licensee can weigh.

Where datasets and models are proven by their contents, agents are proven by their behaviour. A description is not evidence. The Testbed calls a registered agent directly with real tasks across capability areas, customer support, coding, research, sales, and scores what actually comes back. The overall score is the mean of the per-task scores:

Each task is scored one of two ways. Where a verifiable answer exists, it is checked programmatically. Where it does not, a judge model scores the response against a published rubric, and both the response and the judge's reasoning are stored verbatim.

The four capability areas

The tasks are not generic. They are drawn from four real suites, each testing a different kind of competence: Customer Support (tone and genuine resolution under a frustrated customer), Coding (correctness of produced code), Research & Q&A (grounded, accurate answers rather than confident guesses), and Sales (engaging a real objection or writing a follow-up without inventing capabilities).

What the judge actually judges

For tasks without a single verifiable answer, the judge model scores against a published rubric written for that specific task, and the rubrics are pointed. A sales rubric, for instance, asks the judge to reward a response that engages the specific objection with real substance and an honest limitation, and to penalise both caving with an unearned discount and inventing capabilities that were never established. The judge's numeric score and its reasoning are both stored, so a low mark can be read, not just seen.

A prospective licensee also gets a small number of real trial calls of their own before committing, scored the same way, under their own questions rather than only the owner's.

Licences are requested and approved, not bought silently. A request records what the licensee intends to do with the asset; the owner approves or declines. The resulting licence is between the two organizations, Origina records and enforces it without being a party to it.

From the licensee's side the whole journey is short and its money model is simple: browsing and reading Trust Reports is free, credits must be held to take a licence, and nothing is charged until the asset is actually used. Each use is metered to a real event, and the royalty pays the creator 85 percent.

Delivery then splits cleanly by asset type, and both paths check the licence on every access.

Files (datasets & models)

A file is delivered through the gateway as a short-lived signed URL. The gateway verifies the licence, mints a URL that expires quickly, and records the delivery; the bytes then stream directly from object storage, never back through Origina's server. When the licence lapses, new URLs simply stop being minted, access ends without anyone having to claw a file back.

Agents

An agent cannot be handed over as a file, so it is proxied: the licensee calls Origina, and Origina calls the agent. The endpoint URL and credentials never leave Origina's servers.

The two paths are different mechanisms for the same guarantee: access depends on the licence staying valid. A signed URL that stops being minted and a proxy that stops forwarding are the file and agent versions of the same idea, delivery is a privilege of a live licence, not a permanent handover.

Every consumption of an asset, a dataset retrieval, a model fetch, an API request, an agent call, is recorded as a usage event. Usage is append-only: events are written, never edited or deleted, which is what allows any later number to be traced back to them.

Metering is uniform across delivery types. A file retrieval through the gateway and an agent call through the proxy both produce the same kind of billable event, differing only in their event type and quantity. That uniformity is exactly what lets the royalty engine in the next section treat every asset the same way.

A metered event falls into one of two economic classes, separated only by whether a licence stands behind it. When one organization consumes another's licensed asset, the event bears a royalty: priced at a fixed platform rate and shared with the creator. When an organization serves its own agent through the gateway, no creator sits on the other side, so the event bears a platform infrastructure fee instead, a small charge for the metering, provenance, and audit the gateway performs on every call. Both are recorded identically; only their settlement differs.

A royalty statement turns a period of usage into money owed. The gross is simply metered quantity times the licence's unit rate, kept in whole cents so nothing drifts:

The platform takes a fixed fee, 15% by default, and the creator receives the remainder. The fee is rounded first, and the payout is defined as what is left, not rounded independently:

A statement is born in draft. It becomes a binding obligation only when a platform admin reviews and issues it, the one deliberate human checkpoint, at which point it posts to the ledger. Generation is idempotent: the same licence and period never yields a second statement, guarded both in code and by a database uniqueness constraint.

Statements live inside financial periods. A period accumulates statements while open; closing it locks the period so no new entries can be posted into a window that has already been reconciled.

This is the immutability principle applied to accounting: you cannot change what a closed month reported. If something must change, it changes forward, a new entry in a new state, leaving the original reconciliation intact and auditable.

Consuming organizations hold a token balance they spend on usage. Tokens are bought with money at an admin-set, versioned exchange rate. Both conversions round deliberately, and in opposite directions.

Buying rounds down, so a buyer is never credited a fraction they did not pay for:

Spending rounds up, so the platform never eats a fractional token on a debit:

The balance itself is never stored as a mutable number. It is the sum of an append-only token ledger, computed on read, so the displayed balance and the transaction history can never disagree.

Money moves in two directions, and the platform handles them separately. Money comes in when an organization pays, a subscription, a credit top-up, an invoice, settled by card or a payment provider. Money goes out when a creator is paid their royalty. Each flow is confirmed by the provider before the platform treats it as real; a payment is a fact only once the provider says so, never because a button was clicked.

Two providers are wired in for real: PayPal (used both to take payment and, via payouts, to pay creators) and Flutterwave (card and local rails, with an African market in mind). Provider webhooks are signature-verified before they are believed, so a forged "payment succeeded" call cannot credit an account.

Subscription plans

Consuming organizations subscribe. Plans are defined in code, not the database, because changing a price is a commercial decision, and each customer's agreed price is captured on their subscription at signup, so changing a plan never retroactively reprices anyone.

Discovery ranks assets by a relevance score. The current engine is honest keyword matching with a trust tie-break, not semantic search, which is the destination rather than where it is today. When a query is present, points accrue by where the match landed:

Everything a person can do in the console, a program can do through the public API under /api/v1. The developer platform is how an organization automates the platform rather than clicking through it, with three real primitives.

API keys authenticate external code acting on an organization's behalf. Machine identities are non-human credentials with revocable secrets, letting a licensee's backend talk to the gateway server-to-server with no person in the loop. Webhooks run the other way: when an event of interest happens, Origina calls the developer's URL, signed, retried, and with each delivery tracked.

Delivery does not end at the browser. A licensee's real workflow is a pipeline, so the same guarantees, a valid licence, metered usage, revocable access, are exposed as a surface a machine can drive. The Origina SDK (Python, zero third-party dependencies) is the on-ramp: one machine-identity key authenticates every call, and each capability maps to a real scope the credential must hold.

Verification & the deployment registry

A licensed artifact eventually leaves the browser and runs inside the licensee's own infrastructure, where a signed URL or a proxy can no longer reach it. Verification closes that gap: a running deployment checks in, proving its licence is still active and receiving a short-lived token. Each check-in records where the artifact is running, so an owner sees the live footprint of a licence, and a revoked licence stops verifying, which is how revocation reaches an artifact already at rest. Running on more deployments than a licence was sold for is flagged, never silently blocked, a billing signal rather than a kill switch.

Gateway sessions

For file-heavy work the gateway also runs as a session: the licence is validated once when the session opens, many chunk deliveries happen inside it, and one honest usage event is recorded when it closes. The same machine-identity key that verifies and reports also pulls the files, so there is no separate credential system to manage.

Agent sessions

An autonomous agent gets a stronger construct than a static key: a just-in-time session, opened for a declared purpose, with a blast radius, a total spend cap the session enforces on itself, and an instant kill switch. A runaway or prompt-injected agent can spend only up to its cap before its own session refuses the next call, and the cap holder can revoke it immediately on top of that.

Attestation & provenance

Two features answer the questions an enterprise asks before it trusts an asset in production. The AI Passport is the cryptographic identity of an asset, the SHA-256 of every file it is made of, so a copy running anywhere can be proven identical to what Origina registered, unchanged. The AI Bill of Materials is its provenance: an agent declared as fine-tuned from a model and trained on datasets, with compliance computed live from each dependency's real licence state, so the whole chain is flagged the moment a linked licence lapses.

Underneath every feature is one access model. A user authenticates (passwords are bcrypt-hashed, sessions are real tokens). A user belongs to one or more organizations through a membership that carries a role, owner, admin, or member. And what a member may actually do is decided by permissions written in a single "resource.action" vocabulary.

The unit of ownership is the organization, never the individual, every asset, licence, and balance belongs to an org. People join by invitation, and the same person can hold different roles in different organizations. Crucially, access is checked against the specific organization on every request; possessing an identifier that appears in a URL is never mistaken for permission to use it.

Two domains listen quietly to everything and react. Both are driven by the event bus, and neither knows the other exists, one event produces both a message to a person and a line in the permanent record.

Notifications are delivered with real delivery tracking, retries on failure, and per-user preferences about what is worth interrupting someone for. (The email transport itself is currently a stub, an honest current limit, stated rather than implied.) The audit log is the counterweight: an append-only trail of security- and money-relevant actions that cannot be edited, so the record of what happened is itself immutable. An organization can export its own unified trail, credential, verification, usage, and licence events in one chronological file, as CSV or JSON, to hand to an auditor.

Sentia is the platform's assistant: you can ask it, in plain language, about your own organization's real state, what you have licensed, what a licence's terms are, your royalty balance, an asset's trust breakdown, its verification status, your collections. It answers by calling real tools against real data, not by generating a plausible-sounding guess.

The core entities and how they relate. Postgres holds metadata and records; files themselves live in object storage, referenced by checksum. This separation is deliberate, the database is the system of record, not a filesystem.

Notice what is derived rather than stored: a trust report is a function of an asset's evidence, a token balance is a function of a ledger, a royalty is a function of usage. The entities above are the facts; the numbers users see are computed from them.

Access to organization data requires both authentication and verified membership of that specific organization. Knowing an identifier is not access, identifiers appear in URLs and leak through logs and referrers, so membership is checked on every request, never inferred from possession of an id.

Agent credentials are encrypted at rest and never returned by any API. Any user-supplied URL the platform will call is validated against private address ranges, with DNS resolved and the resulting address checked, not merely the hostname string, to close off server-side request forgery.

Endpoints that accept a secret token from an unauthenticated caller are rate limited, as are operations that spend money with external providers. Security-relevant actions are written to an append-only audit log.

The two sides of the marketplace are charged differently, because they are different. Creators publish and license without a subscription; Origina earns its platform fee on royalties actually generated. Organizations consuming assets subscribe, with a monthly credit allowance included.

Charging supply an access fee before it has earned anything suppresses the very supply a marketplace depends on. Creators are already monetised through revenue share; charging them twice would be both unfair and self-defeating.

Usage is metered per event at fixed platform rates. Rates are not negotiable per licence, letting two parties agree an arbitrary rate would undermine a platform-level royalty architecture, since the same activity would be worth different amounts depending on who recorded it.

A third case sits alongside the two marketplace sides: an organization that uses Origina purely as infrastructure, serving its own agents to its own customers without listing anything. There is no royalty to share, so the platform charges a small per-call fee for what the gateway does on every call: meter it, hold it against a live bill of materials, and keep it in an exportable audit trail. The fee is a single platform lever, set deliberately far below the cost of building that metering, billing, and audit in-house, and it applies only forward, never to usage that predates it. This is what lets a company adopt Origina as a billing and compliance layer, not only as a marketplace.

Stated plainly, because a whitepaper that blurs the built and the planned is worth less than one that separates them.

Every core concept in one place. Type tags: entity, process, money, record, rule.