Confirming what the default rule gives the employer: stages and deadlines

The default rule assigns to the employer the rights in software, designs and data an employee creates within the scope of the job. Confirming this in practice means assembling the employment record, the assignment trail and proof of authorship, then closing the file before a dispute, an investor request or a departing engineer forces the pace.

What changes once the default rule is invoked

Nothing changes in the underlying entitlement. What changes is proof. Until someone assembles the record, the employer's position exists only as an assumption shared by everyone in the room. A due-diligence request, a departing employee, or a licensing partner asking for the chain of title turns that assumption into a document that either exists or does not.

The clock starts earlier than most teams expect. If a component was licensed rather than built in-house, the technology contract may carry its own audit clause, and an audit right is invoked without notice technology contract before anyone has finished mapping who wrote what.

Steps to confirm the position

1. HR or the hiring manager pulls the employment contract and the job description in force at the time the result was created.
2. The person who managed the project lists every contributor, including contractors and interns, and marks who was on payroll and who was not.
3. In-house counsel or the external adviser checks whether any contributor sits outside the standard employment relationship — a freelancer, a seconded consultant, a co-founder without a contract.
4. The same reviewer collects evidence of authorship: repository commit history, design files with timestamps, dataset build logs.
5. The reviewer flags any gap — missing contract, unclear scope, a contributor paid through an invoice rather than payroll — and routes it for a decision before the file is treated as closed.
6. A named owner signs off the file and stores it where a future buyer, auditor or court can find it without a search.

Who decides and how long it takes

Inside the company, no external body needs to decide anything if every contributor was an employee acting within scope. The file is confirmed once the named owner signs it. A dispute changes this entirely: a contractor claiming co-ownership, or a former employee asserting a personal stake, moves the question to whichever forum the underlying contract or the applicable employment framework points to, and that forum sets its own calendar.

Common forks

If every contributor was on payroll and the work sits squarely inside their job description, the file closes at the internal sign-off stage — no external step is needed.

If a contractor or a co-founder contributed without a written assignment, the file cannot close until that gap is resolved, either by a signed assignment or by a documented decision to accept the risk.

If the result later feeds into a tokenised product or a digital asset offering, ownership questions can resurface in a different register — for instance, when a stablecoin peg is challenged: who decides and becomes relevant, the underlying code's ownership file is one of the first things a counterparty will ask to see.

If the other side does not respond to a request for confirmation or a signature, the file stays open and the gap is recorded as unresolved rather than assumed favourable.

Sources and limits

This page does not confirm ownership of a specific file. It describes the stages a team should follow to build the record that confirms it. Reading it does not replace the review itself, and it does not tell you whether a particular contract, dataset or design already carries a defect.

It also does not cover valuation. Once ownership is confirmed, a separate question is what the confirmed asset is worth before it is pledged, licensed or sold — that question sits closer to asset report before a right is pledged and its than to an ownership file.

Nor does it cover the debtor side of a transaction built on that asset. If the confirmed result later underlies a claim someone intends to sell or assign, the cost of getting that step wrong is a separate question, closer to debtor report before selling the claim in practice.

Reviewed on 2025-01-14. No external act is cited on this page because the procedure described here does not depend on any single provision; it depends on the employment record and the assignment trail a team assembles itself.

Related publications

Where the default rule does not fit the situation, the alternative is to displace it in advance. See Drafting the contractual override ownership of results for the stages of setting a different rule before the work is created rather than confirming the default one afterwards.

FAQ

How long does confirming what the default rule gives the employer take in practice?

Where every contributor was an employee acting within scope, the internal review typically closes in one to two weeks. A flagged gap — a contractor without a written assignment, a co-founder with an unclear role — adds anywhere from a few weeks to several months, depending on how quickly the other side cooperates.

Which documents are needed to start?

The employment contract in force when the work was created, the job description, a list of every contributor with their status (employee, contractor, intern), and whatever evidence of authorship exists — commit history, design files, build logs. Without these, the review cannot begin.

What happens if the other side does not respond?

The file stays open, not closed in the employer's favour. A non-response is recorded as an unresolved gap, and the team decides whether to press for a written confirmation, accept the residual risk, or escalate to the forum the underlying contract points to.

— Vaidas Kudirka, AURELIS