How it works
An operating model, not a filing cabinet.
Ownership questions are answered continuously because the record is maintained continuously. Five steps, in the order a real estate gets built.
Register what exists
Create or import entities, brands, software, IP, domains, accounts and agreements. Each object gets a stable identity that the rest of the graph can point at.
Connect the relationships
Model ownership, use, custody, licensing, creation, dependency and package membership as explicit, typed, effective-dated relationships.
Attach and verify evidence
Link assignments, agreements, registry records and contribution evidence. AI can propose facts; people verify the material ones before they are trusted.
Keep the graph current
Integrations, reminders and explainable rules surface changes, expirations, gaps and conflicts — without silently overwriting a verified legal fact.
Use the record
Answer ownership questions, generate schedules, prepare a transfer or open a scoped diligence room from the live graph instead of rebuilding the story.
The unit of proof
An assertion, its evidence, and the person who checked it.
Most systems store ownership as an editable field. That field cannot tell you whether anyone verified it, what it was before, or which document supports it — which is exactly what gets asked under pressure.
Here, a claim is an assertion with a source, a status and a reviewer. The current state is what the verified assertions resolve to, and the previous state stays queryable.
- Supports
- Ownership of core-ledger contributions
- Content hash
- sha256:4f9c…a1d2
- Grantor
- Northgate IP
- Grantee
- Northgate Ltd
- Asset
- core-ledger (shared component)
- Territory
- Worldwide
- Term
- Rolling, 90 days' notice
- Exclusivity
- Non-exclusive
- Sublicensing
- Not permitted without consent
“Do we own our core product?” has a structure.
It is not a yes. It is a path, each step of which is either evidenced or a gap you can now see — which is the difference between a position you can defend and one you are hoping about.
- ContributorPerson
- Contractor agreementAgreement
- RepositoryEvidence
- Software componentAsset
- AssignmentAgreement
- IP ownerEntity
- LicenceRight
- Operating entityEntity
- BrandBrand
Where it sits
It does not replace the systems you already run.
Each of these answers its own question well. None of them answers the ownership question across all of them — which is the gap Intangible HQ exists to fill.
| You already have | It knows | Intangible HQ adds |
|---|---|---|
| Digital asset management | Creative files and brand usage | Legal and economic ownership, contracts, package composition and transfer context |
| IP management | Registered rights and docketing | Software, domains, operational custody, economic packages and provenance |
| Contract lifecycle management | Contracts and their clauses | The assets and rights those clauses govern, and their position in the ownership graph |
| Entity management | Companies, officers and shareholdings | The intangible assets and rights flowing between those entities |
| Git and source control | Code and who committed it | Contributor agreements, ownership evidence and chain of title |
| SCA and SBOM tooling | Dependencies and their licences | How a third-party component affects a brand package and a transaction |
Start with what you already know.
Import the entity list, the domains and the trademark schedule you already keep. The graph is useful long before it is complete.
Evidence-backed relationships Multi-entity by design Built for transfer and diligence