an operating system for the space between the tools
None of them know the whole event.
One model that knows the event, the venue, the crew, the shift, the ticket, the payout, the artefact and the settlement state — and makes them agree in operational time.
The system BlackMenta references is a full-stack coordination layer for live events. It does not replace payment rails, ticketing, staffing tools or accounting. It coordinates the operational truth across them, in compressed time. This page is the architecture brief — drawn before the operating entity incorporates, by design.
Four criteria. If any fails, the architecture is wrong.
One event, one model
One event object connects venue, crew, ticketing, payouts, sponsorship, compliance and reporting. If the same event exists as six different spreadsheets, the system has failed.
State changes when the event happens
Not 30 days later when PDF invoices are reconciled. Shift end, ticket scan, payout eligibility and exception flags should be near-real-time objects.
Every action leaves an artefact
Who did what, when, under which obligation, with which counterparty. Receipts are not decoration; they are the operating surface.
Coordinates, doesn’t replace
Stripe, ticketing tools, staffing systems and ledgers can remain components. The layer coordinates the space between them.
Four review lanes. Architecture-first.
Architecture review
For engineers, integrators and platform people who want to understand the object model and operational loop before a pilot integration.
hello@ → RM.02 venue / promoter / festivalPilot conversation
For mid-size festivals and venues considering being the first deployment partner. Swiss-track preferred but not required.
preview@ → RM.03 counsel / complianceBoundary review
For legal and compliance review of the entity wall, custody perimeter, regulated-activity scope and CASP-track exposure of the operating entity.
legal@ → RM.04 reviewer / capitalControlled disclosure
For qualified reviewers. Spec materials are staged through formal DD; this page is not an offer, solicitation or financial promotion.
hello@ →What “operating system” means here.
The phrase “operating system” is overused. In this category, it has a narrow meaning — coordination layer, shared truth, operational time. The four-part test is on Sheet 01 above; this sheet states the category boundary.
Nine objects the system has to understand.
A true live-event operating system is not a nicer CRM. It is an object model where each operational fact attaches to the right event, person, counterparty, timestamp and settlement state.
The event
The master object. Date, location, capacity, stakeholders, contractual perimeter, operational state and proof requirements all hang from here. Every other object references it.
The venue
The physical constraint layer. Access windows, zones, load-in, safety rules, insurance and local compliance obligations. Defines what is operationally possible at this site.
The crew
Verified workers. Roles, credentials, availability, attendance, shift proof, payout state and dispute trace. The named, accountable layer between event and execution.
The shift
The atomic work unit. Scheduled time, actual time, approval, exception, rate, payout trigger and compliance evidence. The receipt of work done, machine-readable.
The ticket
Demand, attendance and revenue signals. Not just admission — a reconciliation input for the event ledger and a settlement trigger for downstream parties.
The payout
Money movement is downstream of proof. Approved shift, verified counterparty, prefunded pool, settlement rule. The system never holds funds — PSPs do — but it conditions release.
The compliance artefact
Contracts, waivers, invoices, worker documentation, risk acknowledgements and audit logs — tied to the event object, not loose in someone’s inbox.
The exception
Late arrival, role mismatch, safety issue, payment hold, dispute or missing credential — visible before it becomes a crisis. First-class object, not a footer field.
The sponsor deliverable
Brand exposure terms, activation windows, attribution counts and sponsor-side proof. The piece of the event that funds parts of it — modelled, not improvised.
Not replacing tools. Replacing the space between them.
Each tool class below is good at what it does. None of them know the whole event. The gap between them is the only place this system sits.
The operational loop. Five phases.
The system runs one loop per event. Each phase has explicit inputs, outputs and exit conditions — no implicit waiting on email confirmations.
Two companies. One wall.
The separation is structural, not cosmetic. The holding owns and licenses intellectual property. The operating entity conducts business, holds customer relationships and bears operational risk.
BlackMenta Ltd
- Owns trademarks
- Licenses IP to operator
- Holds reserves
- Conducts no operations itself
Operating Entity
- Conducts regulated activity
- Holds customer relationships
- Raises capital through formal DD
- Bears operational risk
The wall is also restated on /home · Sheet 03. Same wall, different page; both pages tell the same truth.
First proof: a mid-size Swiss festival.
Small enough to fail safely. Concrete enough to prove the thesis. The first deployment proves coordination, not vanity scale — one event, end-to-end, with all nine objects in flight at once.
5k–15k attendees
Enough operational complexity to matter. Crew, vendors, ticketing reconciliation, sponsor deliverables, exceptions in real time. Not so large that the first failure becomes a public crisis.
Switzerland
Specific jurisdiction, specific operator legal frame, specific payment rails and ticketing partners. The first proof should not be jurisdiction-portable on day one — it should be deeply local.
End-to-end · single event
All nine objects exercised in one operational loop. Artist, venue, crew, promoter, attendee, sponsor — one ledger, one reconciliation surface, one set of receipts at the end.
Reduced coordination overhead
If the operator and venue do not spend less time chasing facts after the event than they would have without the system, the architecture is wrong and must be rebuilt. There is no other proof.
Detailed brief is gated.
This page is the public sketch. Object-model schema, integration patterns, settlement rules and pilot spec are released progressively via auth.blackmenta.com — to engineers, festivals, counsel and reviewers who name a route.
Other pages, in any order.
Home · the thesis · the people · the voice · the receipts.
The holding entity, the legal wall, the public surface
BlackMenta Ltd · № 16988667 · the public cover sheet for the IP holding entity behind this brief.
Why the live event economy needs rebuilding
$652B industry running on spreadsheets and 30-day settlement. Five problems in parallel, five forces converging in 2026.
The filter, the origin, the standard
The ten-year test. House rules. Non-negotiables. Counsel of record. The two anchors.
The silence, the lowercase, the doctrine
Silent build phase. No campaign, no newsletter, no waitlist. Why this reads like a drawing, not a brochure.
Regulatory, jurisdictional, privacy references
Specific statutes. Jurisdictional map. Privacy stance, plainly stated. Glossary, FAQ.
Notes.
- N.01 This is an architecture brief, not a roadmap. Object model, loop, and pilot spec are subject to change before architecture lock (Q3 2026). → see Sheet 02 · 02.3
- N.02 The system never holds customer funds. Money moves through licensed PSPs; the system conditions release based on proof state. → see Sheet 03 · OBJ 06
- N.03 Tools listed by name (Stripe, Eventbrite, etc.) are illustrative of category, not exclusive partnerships. → see Sheet 04 · tool diff
- N.04 Pilot target is mid-size Swiss festival, specific operator pending. Geography may extend, but never before pilot proves coordination. → see Sheet 07 · P.02
- N.05 Architecture questions: hello@blackmenta.com. Answered within five business days.