Marketing that responds
while it still matters.
The signals are already in your business, scattered across teams and systems. Serum brings them together into one coordinated, governed decision.
Built to help enterprises discover opportunities worth pursuing, make better commercial decisions, strengthen customer relationships, and act while it counts — with people in control of every consequential step.
A human-governed agentic operating system for marketing decisions.
Specialist packs across promotions, loyalty, media, content, audience, brand, commerce and measurement.
Those packs compose. Each owns its own domain, and they assemble into one accountable decision across the boundaries between them.
The fourteen-pack portfolio, a worked decision with its real numbers, and the governed loop behind it.
Paid-social conversion rate 6% below target
Detected 2 days ago · HIGH severity · Marketing Intelligence
Shift budget toward inventory-available markets, refresh the creative driving the conversion decline, and simplify the mobile landing page.
Where could better marketing
decisions create value?
Explore the business questions Serum's specialist packs are designed to address — from improving incentives and media investment to getting usable content into market and helping customers complete the next step. Each pack brings a distinct perspective; a client decision can draw on several.
Fourteen specialist domains. Each owns a distinct business question, and a single client decision can draw on several of them at once.
Point at a pack, or select one, to see the situation it is built for and the decision it is designed to put in front of a business owner.
Built and running. Carries a registered identifier in the product, and appears in demonstrations and scenarios.
A described decision and the research behind it. Not built, not configurable, and not demonstrated anywhere in this product.
Showing all 14 packs
Every real deployment is configured. A pack supplies reusable agents, decision logic, workflows and measurement patterns. A deployment adds the client or agency partner's objectives, data, policies, people and systems.
Specialist intelligence,
configured around your business.
Serum brings a governed foundation, reusable marketing expertise and your operating context together. The foundation manages the decision. Solution packs contribute specialist reasoning. Client configuration connects that reasoning to the objectives, evidence, responsibilities and systems involved in a real use case.
Improve incremental reactivation among dormant members while preserving the promised offer.
With the metric definitions, policies, commitments, approval rights and observation windows that apply to it.
Leads: the incentive’s mechanics and its economics.
Member state, and what the programme benefit means.
Who is eligible, and whether the groups compare.
What the evidence supports — including what it does not.
Whether to continue, change, constrain or stop a temporary incentive inside its remaining commitments.
Evidence · versioned recommendations · challenge and refinement · version-bound approval · action records · observation and learning
Four specialist packs compose one governed decision: Promotions leads, with Loyalty, Audience and Measurement contributing under a shared decision contract. A human challenge re-reasons the case into a new version. This runs today on seeded evidence.
Composition as the ordinary way a client organization operates, rather than as a demonstrated case. Platform organizations run with one configured pack today; making composition the general runtime is structural work that has not been done.
Serum helps a team reason about and govern decisions across the operating environment it already has. Marketing, content, CRM, commerce and analytics systems remain the systems of evidence and of action.
Those connections are requirements, not existing integrations. Outbound execution to a live system is planned; today an authorized action produces a labelled in-process record and contacts nothing.
A continuous governed loop —
not a one-time linear workflow.
Learning informs later signals, diagnoses, and recommendations. Evidence runs through the entire loop. Different agents contribute at different stages. Human involvement changes according to authority, risk, and the deployment model.
Nothing crosses into Execute without an approval. The stages before it assemble and compare; the authorization is what releases the ones after it.
Signal
Notice a meaningful change against the objective.
Detection runs against configured definitions over seeded evidence.
Monitoring observes configured metrics and data sources and detects deviations from targets or baselines that meet configured severity thresholds.
Defines what matters — signal definitions, thresholds and severity rules — and validates the context behind a detection.
Metric observations, target configurations, baseline values, and the population and period the objective is stated over.
A signal record: its population, period, severity, detected time, pack and status.
A change is noticed while there is still time to respond to it, rather than in the next reporting cycle.
Metric observations, target configurations, baseline values
Effect on next stage: The signal triggers evidence assembly and diagnosis.
The right answer depends
on more than one view.
A strong result in one domain can hide a problem in another. Serum's specialist packs bring those perspectives into the same decision, with clear ownership of the evidence and of what it means.
No pack votes, scores or overrules another. A domain states what it owns, and that statement can constrain the whole recommendation — including by refusing a reading the arithmetic invites.
“A useful recommendation must account for what the organization can deliver — production capacity, lead times, cost, approvals, and existing commitments.”
That is what configuring Serum consists of: the evidence, the commercial commitments, the operational constraints and the decision owners become inputs. It describes what the platform needs — not connections that are already in place.
Intent
A candidate advantage, to be tested in a pilot. What Serum is built to help with. No client outcome has been measured, so none is claimed.
Established platforms already do orchestration, agents and review, and they do them well within their own domains. Serum's claim is narrower and testable: that governing the intersection — which pack owns which meaning, who may decide, on what evidence, bound to which version — is what makes a cross-domain action dependable enough to authorize. That is a candidate advantage, and a bounded pilot is how it gets tested rather than asserted.
Built for your team,
your agency, or both.
The same decision framework can support different operating relationships. None of the three is the recommended one. What changes between them is who prepares the work, who controls the evidence and systems, and who holds the authority to act.
The agency uses Serum to standardize decision quality, respond to signals faster and encode its expertise in repeatable workflows. The client receives conventional outputs, or selected visibility into them.
Runs today as a single governed organization, with preparation and authorization held by different people.
Agency team, within its governed scope
Agency
Agency, within contracted authority
A separate authorized agency role
Data access and ownership are contractual and configuration choices. Operating the software transfers ownership of nothing. Teams adopting any of the three need agreed metric meanings, explicit decision rights, accessible evidence and a defined action workflow — an agency can encode and apply expertise, and a client can retain or delegate control within agreed boundaries.
A promotion beat its redemption plan
and still missed what it was funded for.
Illustrative scenario · modeled projection · informed by researched cases
Member Week was funded to bring dormant members back. At the checkpoint, redemption was comfortably ahead of plan — and dormant-member reactivation was nowhere near its target. Continuing unchanged would have finished over the approved envelope.
The cheapest way out was closed. An overlapping app offer was contractually locked — it could not be withdrawn, and its advertised member value had to be preserved. An earlier alternative that suppressed it was invalidated and kept in the challenge history as infeasible, not as the option that won.
What survived was a revised plan that keeps the commitment: restrict discretionary stacking, move broad incentive into the dormant-member reserve, and finish inside the envelope.
What the promotion was funded to spend.
Over the envelope, with the objective still missed.
Inside the envelope, and the locked commitment kept.
$30,000 less than continuing — a modeled difference between two projections, not money anyone earned. The vertical line is the approved envelope.
The specialists behind this decision
Four of Serum's packs contributed to Member Week — the ones whose domains this decision crossed. Each owns its own meanings and states its own limits. None of them votes, none is scored against another, and none can overrule another's definitions.
Assembled, attributed, and authorized by one person
Which incentive fits the objective, the funding and the constraints?
Evaluated the temporary incentive and its economics — redemption against plan, envelope consumption, and what the remaining investment would buy.
A different decision draws on different packs. The full portfolio is below.
- See whether the campaign is meeting the objective it was funded for, while there is still budget left to direct.
- Compare the feasible changes on their economics, with the infeasible one visible and marked as such.
- Keep a commercial commitment that cannot be broken, rather than discovering it after the fact.
- Take Finance one specific, authorized decision — with its alternatives and its named gaps attached.
The 60- and 90-day retained-value outcome stays a named pending result throughout. It is not filled in from a benchmark.
See how the decision changes.
Representative marketing situations in which evidence, commercial constraints and human judgment shape the next action. Each one shows the specialist contributions, the alternatives and what the team would measure — and says plainly what you can open today.
- The tension
- Redemption is running ahead of plan while reactivation sits at a third of the objective the spend was funded to move, and the envelope is on track to be exceeded.
- Who contributes
- Promotions · leadsLoyaltyAudience & Customer IntelligenceMeasurement & Experimentation
- What the team measures
- Reactivation against the funded objective
- Projected close against the approved envelope
- Retained programme value, once its window closes
Open the demonstrationSign-in required. The hardened sign-in, carrying the case portfolio as its destination. Checked 2026-10-23 (responded 401).
- The tension
- Assets pass internal review and then fail a retailer specification, and the rework lands in the window that was meant for delivery.
- Who contributes
- Content Operations & Supply Chain · leads
- What the team measures
- Share of assets requiring rework
- Rework effort released
- Usable delivery timing against the retailer window
Open the demonstrationOpens directly. The Make AI Work page, with its own themed sign-in at /makeaiwork/login. Checked 2026-10-23 (responded 200).
- The tension
- Delivery looks healthy in aggregate while the spend reaching qualified audiences, and the commitments already made, pull in different directions.
- Who contributes
The packs this would compose are design-stage, so no contribution is named here.
- What the team measures
- Qualified-spend share
- Contribution against the baseline allocation
- Commitments and cancellation terms honoured
The media pack is a planned domain. What can be opened here is a concept prototype, labelled as one, and it demonstrates an intended shared agency–client environment rather than a built capability.
Open the demonstrationOpens directly. A target-state concept prototype using fictional seeded data. Not a Serum deployment and not a measured result. Checked 2026-10-23 (responded 200).
- The tension
- Awareness holds up while buyers stall before a shortlist, and the brief that would change it is written from last year’s proposition.
- Who contributes
The packs this would compose are design-stage, so no contribution is named here.
- What the team measures
- Buyer progression through the stages that stall
- Message adoption across the brief’s outputs
- Eventual commercial outcome, on its own horizon
A described situation, not a demonstration. The packs this would compose are design-stage, and no implementation of this scenario exists — so there is nothing to open, and a link here would be an invented route.
- The tension
- Interest concentrates on configurations that are not locally available, and the routing decision and the media decision are made by different teams on different evidence.
- Who contributes
The packs this would compose are design-stage, so no contribution is named here.
- What the team measures
- Share of demand routed to available supply
- Test drives arising from routed demand
- Incremental delivered sales, on the sales-cycle horizon
A described situation, not a demonstration. No implementation of this scenario exists in this build. An earlier prototype URL is not a destination this page may point at.
Working tenants
Two real organizations running on the platform today. A reviewer with credentials signs in through the shared hardened sign-in; there is no public preview of either.
- Northstar Home & Living — A marketing-engine tenant. Reached through the shared hardened sign-in; there is no separate public preview route. Checked 2026-10-23 (responded 401).
- Brightmark Retail Group — A content-operations tenant, on the same sign-in. Not the concept prototype — presenting it as one would misdescribe a working deployment. Checked 2026-10-23 (responded 401).
What you can use now —
and how Serum becomes operational.
Serum distinguishes clearly between working capabilities, live-model generation from seeded data, active development, and partner-dependent functionality. No capability is misrepresented.
How to read these statuses — and how they were verifiedFilters · provenance · audit
Live-model reasoning · Seeded prototype data: The underlying prototype data and evidence records are seeded. Diagnoses and recommendations are generated by live-model reasoning from that data — not retrieved from a bank of pre-authored outputs — with a deterministic fallback when a live call cannot complete. Each run records which mode produced it, so this is a description of the pipeline, not a claim about any particular run. Production data connectors are not yet active. Downstream execution and observed outcomes are simulated where identified.
Independently auditedWhat that does and does not mean
Independently adversarially audited and remediated. An independent audit exercised this invariant, every finding against it was fixed, each fix carries a test that fails without it, and the result is deployed. The date and build shown are when that test landed. This is not a certification and not a compliance attestation.
Capabilities carrying the Audited tag are the ones the record below earns. The tag is derived from that record by arithmetic, not set on a row — a control that loses its artifact loses the tag without anyone having to remember to remove it.
- R1 — One open approval request per recommendation version, and one decision per request. The terminal-version guarantee is service-enforced; it is not a database "one terminal decision" invariant.backend/tests/test_submission_version_race.py · guard landed 2026-08-26 · d06c6c7
- R2 — A row lock plus a partial unique index prevent two simultaneously-open, independently-decidable review requests for one asset version. Rejected content versions are terminal.backend/tests/test_content_review_submission_race.py · guard landed 2026-08-27 · 951e9ed
- R4 — Database TLS is verified by default (verify-full, CERT_REQUIRED, hostname checked) and fails closed without a CA. This is verified at the code level; the presence of the CA in a given deployment remains an operational check.backend/tests/test_database_tls.py · guard landed 2026-08-26 · ffc8dd3
- R5 — resolve_client_ip is the sole authority over the client address, and both start paths disable Uvicorn's proxy middleware.backend/tests/test_client_ip_and_login_timing.py · guard landed 2026-08-23 · 1e89ecc
- R6 — Organization enumeration is behind platform-operator authority and fails closed.backend/tests/test_platform_operator_authority.py · guard landed 2026-08-22 · ea0be8d
- R7 — The refinement output cap is raised above the value that truncated valid responses, a live-call failure is logged rather than swallowed, and the deterministic fallback message states the real cause.backend/tests/test_refinement_output_cap.py · guard landed 2026-08-26 · d9467f3
- R8 — Bake-off failure legibility, including a failed second ("after") sensitivity call and stale-cache invalidation at eval-set v2.backend/tests/test_bakeoff_failure_legibility.py · guard landed 2026-08-27 · c82ad4b
This is not a certification and not a compliance attestation, and it does not cover every capability on this page.
R3 — Evidence semantic support. Evidence grounding defaults conservatively to inference; deterministic support-checking is being hardened. Not independently verified, and deliberately untagged.
Independently adversarially audited and remediated. An independent audit exercised this invariant, every finding against it was fixed, each fix carries a test that fails without it, and the result is deployed. The date and build shown are when that test landed. This is not a certification and not a compliance attestation.
Shipped within the last six weeks. The badge is computed from the ship date and disappears on its own as the work stops being recent — it is not a permanent label.
Recommendation versioning
Every edit creates a new immutable version, and approval is bound to one specific version.
Version-bound approval workflow
Submit, approve and reject are bound to one recommendation version. A superseded or already-decided request is refused, and two approvers deciding at once cannot both write.
Separation of duties
Wrong-role and self-approval paths are denied server-side, audited, and shown as governance proofs.
Audit trail with mutation guards
Every governed-loop transition writes an audit event, protected by database-level guards: updates are refused outright and deletion is narrowed to a whole-organization reset that cannot remove a subset of history. This is not an independently tamper-evident ledger — in a single-role deployment the application role retains the ability to clear an organization’s trail, because the in-app reset requires it. Reset is disabled in this shared deployment.
Decision records
Every recommendation, approval and execution is a structured, versioned, auditable record.
Governed workflow coordination
A decision is shown as a sequence of governed steps with the role accountable for each. A step a pack has not configured reads "Not configured" rather than being invented.
Independent audit remediation
An independent adversarial audit was completed and its findings remediated. Each fix is a separate change carrying a test that fails without it, and the remediated build is the one deployed.
Live-model reasoning
Reasoning runs live by default and falls back to the deterministic engine when a live call cannot complete. Each run records which mode produced it, so no surface has to guess.
Diagnosis generation
Diagnoses are generated by the live model operating on seeded prototype data. The evidence-to-conclusion structure is genuine; the inputs are seeded.
Needs: Production data connectors
Recommendation generation
Recommendations are generated by the live model on seeded prototype data. Recommendation structure, versioning and governance are real.
Needs: Production data connectors
Challenge & Refine
A person corrects a specific finding, assumption or piece of evidence and the system re-reasons live from that correction into a new governed version. The correction is recorded first and changes nothing on its own; the version it produces goes through the same approval reset and audit path as any other change.
Signal-to-Action decision workspace
One screen from signal through evidence, diagnosis and recommendation to the approval decision — with the alternatives considered, why each was not preferred, and the ability to elevate one into a new version.
Signal detection and monitoring
Signal structure and evidence assembly are real. The underlying data is seeded.
Needs: Production data connectors
Evidence and provenance labelling
Contributing factors carry evidence ids, basis (evidence vs inference), weight and capability labels. Basis defaults conservatively to inference, and a factor is only ever downgraded, never upgraded — each downgrade is recorded. The deterministic support-checking that decides when a claim may stand as evidence is being hardened, and is deliberately not tagged as independently audited.
Measurement plans
Measurement windows, primary metrics and attribution limitations are defined per recommendation before anything is executed.
Learning record validation
The human validate/reject action, its audit trail and its effect on the record’s status are real. The proposed learning text itself is deterministic, not generated.
Conversational assistant
Answers from the organization’s own seeded records with a citation per answer, and declines off-script questions honestly. No live language model is called.
Measurement (simulated)
Deterministic comparison of seeded baseline and predicted values against a simulated observed value. No live attribution data; the limitations are stated in-product.
Needs: Production attribution data
Outcome validation against production data
Measurement against real attribution and performance data, which is what turns a measurement plan into an observed result.
Needs: Production connectors · Client data access · A closed observation window
Idempotent execution
One execution request per approved recommendation version, per action. Repeated execute calls for the same version and action return the same request.
Execution (simulated)
Deterministic and in-process, producing a synthetic reference. Labelled everywhere it renders. No live external system is contacted.
Live outbound execution
Real outbound action to media platforms, content systems and inventory systems. This is the capability that turns a simulated execution into a real one, and it is separate from live reasoning, which already works.
Needs: A deployment partner · Configured integration scope · Granted action authority
Organization and tenant isolation
Every governed entity is organization-scoped and destructive cross-organization access is blocked — verified by row counts and identifiers rather than by status code.
Platform-operator separation
Cross-organization operations require an explicitly configured platform operator. Administering one tenant does not confer the ability to reset, snapshot or read another.
Access provenance and hardened authentication
Per-person email and password login for provisioned accounts, with login-attempt and site-gate telemetry recording who reached what and when. Rate-limited, with the client address derived only from a configured proxy chain rather than a caller-supplied header.
Hosted foundation
Running as a hosted deployment: managed Postgres, the API and the web app each on their own platform. Schema is applied at startup by guarded, idempotent statements rather than a migration framework — a deliberate, documented choice.
Multi-organization operation
Four organizations run side by side in one deployment, each with its own solution pack, personas, data and reset. Self-service onboarding and billing are not built — this is multiple organizations operating, not a self-service SaaS surface.
Governed cost and economics transparency
Every agent run records its model, token counts, latency and estimated cost, and the admin console reports live-mode economics per organization. What the reasoning cost is a governed record, not an invisible line item.
Multi-pack composition (demonstrated)
Four specialist packs compose one governed decision: Promotions leads, with Loyalty, Audience and Measurement contributing under a shared decision contract. A human challenge re-reasons the case into a new version. This runs today on seeded evidence.
Multi-pack production runtime
Composition as the ordinary way a client organization operates, rather than as a demonstrated case. Platform organizations run with one configured pack today; making composition the general runtime is structural work that has not been done.
Needs: Structural platform work
Shared and cross-organization collaboration
Shared multi-user workflows and comment threads across organizations. Challenge & Refine is a separate, working capability and is not waiting on this.
Pack configuration surface
An administrative interface for pack-level settings, KPIs and signal thresholds.
Client data sources
Real metric observations from production ad platforms, analytics systems and data warehouses.
Needs: Client data access agreement · Connector credentials
Identity and organizational configuration
Client-specific users, roles, approval thresholds and organizational structure.
Needs: A deployment partner · Identity provider details
Northstar Home & Living
core_marketing
A marketing-engine tenant. Reached through the shared hardened sign-in; there is no separate public preview route.
/login · gated · 401 observed 2026-10-23
Brightmark Retail Group
content_operations
A content-operations tenant, on the same sign-in. Not the concept prototype — presenting it as one would misdescribe a working deployment.
/login · gated · 401 observed 2026-10-23
Start with a decision your
organization can act on.
A useful pilot connects a recurring business decision to accessible evidence, an accountable owner and a measurable outcome. The scope depends on the systems, the workflow and the authority needed to carry it through.
What you bring, and what we define together
Suggested next step
Clarify the decision — The decision boundary, success criteria, the value model and the comparison.
The gates a pilot passes
- 1Define
Select the decision, the scope, the owners, the baseline, the data and the outcome window.
Exit evidence: A bounded decision and a measurement contract.
- 2Shadow
Assemble the evidence and compare recommendations with current practice, without an uncontrolled action.
Exit evidence: Reproducible reasoning, visible gaps and useful human challenge.
- 3Bounded intervention
Connect one limited authorized action path and exercise its controls.
Exit evidence: A versioned approval and an accountable action record.
- 4Observe and assess
Compare forecasts, operational behaviour and outcomes across the agreed window.
Exit evidence: An assessment that separates observed results, estimates and pending effects.
- 5Repeat or expand
Use validated learning to improve the next decision, and decide whether to widen scope.
Exit evidence: A justified next scope, or a decision to change or stop.
What a specific pack would need
Spend and commitments by domain, contribution assumptions, budget authority and cancellation terms.
Measured by: Incremental contribution after marketing and change costs, compared on one horizon, scope and cost basis. (Planned)
An indicative calendar
- Around day 30Evidence established and a first shadow decision taken.
- Around day 60Repeatable decisions and a controlled action path demonstrated.
- Around day 90Evidence assessed and the case for expansion decided.
Indicative timing. Subject to access, data readiness, integration scope, staffing and measurement windows. It is not a researched average and not an unconditional offer.
Two clocks run, and they are not the same one. Pilot delivery starts at kickoff. Business-outcome maturity runs on the outcome’s own horizon, so a day-90 pilot assessment can arrive before a 60/90-day retained-value cohort or a long B2B sales cycle has closed. A pending outcome is pending; it is not a failure, and it is not filled with a benchmark.
Which decision would you improve first?
Start with one decision, the evidence that is already available, and an outcome worth measuring — a pilot proves it on one; the platform spans many. Four questions, and the answers tell us whether a bounded pilot makes sense and what it would include.
Which decision would you
improve first?
Start with one decision, the evidence that is already available, and an outcome worth measuring — the pilot proves it on one; the platform spans many. A bounded pilot is built around the people and systems that can act on it, not around a data programme that has to finish first.