How the system is actually built
This page describes the implementation behind the demonstration environment on this site, not an architecture diagram for a system that does not exist yet. Where something is a boundary rather than an integration, it is described as a boundary.
What this page describes
ASTIN is a working system at demonstration maturity, not a deployed production platform. The distinction matters to anyone assessing it, so it is drawn explicitly.
- Domain entities, events and workflow transitions across the full ownership life cycle
- Server-side persistence that survives restarts, seeded from a versioned fixture
- Role-dependent API views — each role receives a different payload, not a filtered screen
- Ownership updates, allocation reassignment and the ledger effects that follow a transfer
- Document metadata with ordered versions and access levels
- An append-only activity history exposed by the API
- Locale-driven language, currency, seasonality, registry terminology and executing party
- Authentication. The demo switches between simulated identities; there is no login, credential store, session management or account recovery.
- A production database. State is held in a JSON document with atomic writes and a serialised write queue — durable and consistent for a demonstration, not a transactional RDBMS.
- Document content storage. The Data Room demonstrates metadata and versioning; it does not store, encrypt or serve document files.
- Cryptographic immutability. The activity history is append-only because no update or delete path exists in the API, not because records are hash-chained or notarised.
- Live integrations. Registry, letting-operator, payment and identity boundaries are modelled and simulated, not connected.
- Security assurance. No penetration test, certification or formal data-protection assessment has been carried out.
Data model
The domain is modelled as entities and events rather than screens. State is derived from the event history, which is what makes the audit trail meaningful rather than decorative.
Asset
The property: identification, jurisdiction, currency, operating budget, seasonality profile, onboarding status.
Party
Any actor — co-owner, operator, broker, viewer — with a role and a locale.
Ownership interest
A holding in an asset expressed in shares, with a validity period.
Ownership event
An append-only record of every change to the ownership state, with actor, date and reason.
Calendar period
A dated span with a season class, a weight and an availability state.
Allocation
A period assigned to an interest, in weighted units and physical nights.
Decision
The STAY / EARN / HOLD status of an allocation, with the actor and the time it was set.
Ledger entry
A revenue or cost event bound to an allocation, an owner and a category.
Document + version
A categorised document with numbered versions carrying issue date, author, status and access level.
Transfer case
An exit workflow with stages, an asking price, expressions of interest and an execution boundary.
Audit event
Actor, role, action, target and timestamp for every state change in the system.
Roles and permissions
Four roles are implemented, and the payload changes materially between them — not by hiding buttons, but by returning different data from the API.
Full operational control of the asset: onboarding, calendar, allocations, settlement, transfer cases, documents.
Their own interest, allocation and statement. Sees the asset record and the documents their access level permits.
Released inventory, the settlement data they must supply, and the transfer cases they are executing. No access to other owners’ positions.
Read-only, time-boxed, restricted to documents and states explicitly published to that access level.
Role scoping is applied in the API layer on every request, so a role cannot reach another role’s data by manipulating the client. It is authorisation logic, not authentication: the demo has no login, and the role selector openly switches between simulated identities. A production deployment would place real authenticated identities behind the same scoping.
Activity history and document versioning
Activity events are append-only in the sense that the API exposes no update or delete path for them. The client renders them in sequence with actor, role, action and target, and every state change made in the demonstration appears immediately. They are not hash-chained, signed or externally notarised, so this is tamper-evident by construction of the interface rather than cryptographically immutable.
Documents carry ordered versions. A version records its number, issue date, author, status and access level; superseding a document adds a version rather than replacing content, and the current version is derived rather than stored as a flag. The demonstration models document metadata only — no files are uploaded, stored or served.
Persistence and deployment
The demonstration persists server-side to a JSON document written atomically through a serialised write queue, seeded from a versioned fixture. State survives reloads, browser changes and server restarts, and concurrent requests cannot interleave a read-modify-write. It is not browser storage and not hard-coded component state — but neither is it a relational database, and it is sized for a demonstration rather than for production load.
The store is reached exclusively through a repository layer, so moving to PostgreSQL or SQLite for a production deployment is a change confined to one module rather than spread through the application. That migration is a deployment task, not completed work.
The application runs as a single Node process with no external service dependencies and no build step required to serve it. The marketing pages are additionally emitted as static HTML, so they can be served from any static host independently of the demonstration environment.
Privacy and security principles
What is true of this implementation today, stated without inflation.
No third-party tracking
No analytics, no advertising tags, no cookies set by this site. Fonts and assets are served from this origin, so visiting the site discloses nothing to a third party.
No personal data in the demo
The scenario contains no real people. Parties are synthetic and labelled as such, and visitors are asked not to enter real personal data.
Server-side authorisation
Role scoping is applied in the API layer rather than in the interface — though without authentication behind it, as stated above.
Least disclosure by default
Document access levels start closed; widening one is an explicit act that is recorded in the activity history.
Content Security Policy
The server sends a restrictive CSP, frame-denial, MIME-sniffing protection and a referrer policy on every response.
Transport security
TLS is a hosting requirement for production and is documented in the deployment guide, not provided by the application itself.
No security certification, penetration test or formal data-protection assessment has been performed, and none is claimed. Those are deployment activities. The demonstration environment should be treated as a public sandbox: it holds nothing confidential and can be reset by any visitor.
Integration boundaries
The following are boundaries the system is designed around. None is a live integration: the demonstration simulates each exchange rather than performing it, and connecting any of them is implementation work to be scoped with the counterparty.
Notary, land registry or DLD Registration Trustee. The transfer case holds at an execution stage until an authorised confirmation is recorded.
Released inventory out, settlement data in. Modelled as a structured exchange, ready for a reporting integration per operator.
Entirely external. The system records that a stage completed; it never touches funds.
KYC/AML performed by the regulated party in the transaction; the system records the outcome, not the underlying data.
Localisation
Locale governs interface language, number and date formatting, currency presentation, seasonality profile, registry terminology and the identity of the external party that executes a transfer. Switching the demonstration scenario from Gran Canaria to Dubai changes all of these consistently, which is the mechanism by which the product enters a new market.
See it running
The demonstration environment carries a synthetic asset through the entire life cycle, in four operational roles, with persistence — reload and the state is still there.