DEV Community: Leiv Eriksson

Credit data is messier than equity data, always

Leiv Eriksson — Wed, 18 Mar 2026 22:35:11 +0000

Adding bonds, news, and a credit universe to a graph built for stocks

I load the first batch of bond data into the graph and run a quick sanity check — how many Company nodes do we have? The answer is 350. It should be closer to 220. I pull a sample and there it is: the same company, twice. One node carries an equity ticker, a Bloomberg ID, clean edges to earnings and research notes. The other carries a bond ISIN as its primary identifier, floating loose, connected to nothing meaningful. Same legal entity. Two nodes. No relationship between them. The graph I spent two chapters describing as a flexible, expressive data model has just revealed its first real crack — and I haven't even finished loading the credit universe yet.

Where we are

In chapter one, I made the case for a graph over a relational database. In chapter two, I built the foundational schema: Company nodes, ResearchNote edges, earnings events, equity coverage records. It was clean work. Equity research has clean abstractions. A company has a ticker. A ticker has an ISIN. An ISIN is unique. You know where you stand.

That world ends the moment you add bonds.

The graph at this point holds a working equity universe — companies, tickers, analysts, research notes, earnings events. The agents built on top of it can draft a snapshot, prep for an earnings call, pull relevant context. The thing works, for stocks. The mandate now is to expand it: add bonds, add credit news, add a credit coverage universe, and wire all of it into the same graph so that equity and credit research can share context. Simple in theory.

The problem

Bond data doesn't have the same clean identity primitives that equity data does.

An equity issuer is identified by its ticker, its primary exchange ISIN, maybe a CUSIP or SEDOL. These map onto each other reasonably well. You can pick one as your canonical identifier and live with it.

A bond issuer is identified by its legal entity name, a registration number if you're lucky, a Bloomberg issuer ID if you're in that ecosystem, and then each individual bond has its own ISIN — a different ISIN from the equity, a different ISIN from every other bond the same company has issued. A company with five bonds outstanding has at least five ISINs floating around that all resolve to the same legal entity. None of them are the company's "primary" ISIN in any meaningful sense.

When I built the initial Company node schema, I included a primary_isin field. It was designed for equity — the ISIN of the listed share. When I started loading bond terms from the Stamdata connector, the pipeline dutifully populated primary_isin with whatever ISIN it found first. For a credit counterparty with no equity listing, that meant a bond ISIN ended up as the company's primary identifier. Now the dedup logic that relied on primary_isin uniqueness broke silently, and a new Company node was created every time a different bond from the same issuer came through.

That's how you get 350 nodes when you should have 220.

Into the unknown

The first thing I build is the Stamdata connector — search_issuers() and get_all_issues_for_issuer(), pulling bond terms: coupon type, maturity, currency, seniority, covenant flags. The data is rich. Stamdata's coverage of Nordic credit is excellent, and getting 13 BondIssue nodes loaded with full terms feels like real progress.

Then I add the news pipeline. Nordic credit markets run on a handful of wire services, and getting those NewsItem nodes into the graph — linked to the relevant companies and bond issues — is the piece that will eventually make the system feel current rather than archival. The news_writer.py and the migration script go in without drama. News is actually the cleanest of the new data types; a news item has a timestamp, a headline, a body, and a set of entities it mentions. Easy to model.

The context builder is where things get genuinely interesting. Until this point, agents had been querying the graph for structured data and feeding it into LLM prompts as raw field values. The context builder — graph/services/context_builder.py, 235 lines that didn't exist a week ago — is the first piece of code that actually assembles graph data into something an LLM can reason about. It traverses company → bonds → recent news → research notes and produces a structured narrative block. This is the piece I've been building toward.

But I can't properly test it against credit companies because the credit companies aren't properly in the graph yet. And the reason they aren't properly in the graph is the duplicate node problem.

# What we were doing — using bond ISINs as company primary identifiers
company = CompanyNode(
    name="Amwood AS",
    primary_isin="NO0012345678",  # this is a bond ISIN, not an equity ISIN
    asset_class="Credit"
)

# The result: a second node gets created when the equity pipeline
# later encounters Amwood with a different ISIN

The dedup script — scripts/fix_credit_entities.py — does the forensics. 127 duplicate Company nodes. For each duplicate pair, I elect a canonical node: the one with the highest research note count, and critically, the one whose primary_isin looks like an equity ISIN rather than a bond ISIN. Then I re-link all edges — ResearchNote edges, BondIssue edges, coverage records — from the duplicate to the canonical, and delete the duplicate.

# Simplified version of the canonical election logic
def elect_canonical(nodes: list[CompanyNode]) -> CompanyNode:
    # Prefer nodes with equity-style ISINs (bond ISINs become BondIssue attributes)
    equity_candidates = [n for n in nodes if not looks_like_bond_isin(n.primary_isin)]
    pool = equity_candidates if equity_candidates else nodes
    # Among candidates, prefer the one with the most attached research
    return max(pool, key=lambda n: n.note_count)

350 nodes becomes 222. The graph is smaller and more truthful.

What worked

The fix itself is unglamorous — a dedup script, an asset_class tag, a re-linking pass. The lesson it leaves behind is permanent.

The right model separates company identity from instrument identity. A Company node represents a legal entity. It gets a primary_isin only if it has a listed equity — and if it does, that field holds the equity ISIN. Bond ISINs belong on BondIssue nodes, which are their own first-class entities in the graph with their own attributes: coupon, maturity, currency, seniority, covenant flags. The relationship (:Company)-[:ISSUED]->(:BondIssue) carries the connection. You never confuse the issuer with the instrument.

The asset_class field on Company — Equity, Credit, or Both — is a coverage tag, not an identity tag. After the dedup and the Excel coverage universe load, the graph settles at 305 companies: 168 equity-only, 47 credit-only, 90 tagged Both. Those 90 are the interesting ones — companies that a credit analyst and an equity analyst might both have a view on, and where the graph can now start surfacing connections between those views.

# After the fix: BondIssue as a first-class node
class BondIssueNode(BaseModel):
    isin: str                    # bond ISIN — lives here, not on Company
    issuer_name: str
    coupon_rate: float | None
    maturity_date: date | None
    currency: str
    seniority: str | None
    has_covenants: bool

The context builder, once the graph is clean, actually works. Give it a company name; it returns a structured block covering the equity position, any outstanding bonds with their key terms, recent news items, and the most relevant research notes. This is what gets wired into the agent prompts in the next commit cycle. The graph earns its place not by storing data but by traversing it.

What this changed

I had assumed the hardest part of expanding into credit would be the data sourcing — finding the right connectors, navigating the identifier mess, parsing bond terms out of documents. That was genuinely fiddly work. But the hardest part was the schema flaw I didn't know I had until the new data revealed it.

Real financial data will always find the crack in your abstraction. Equity data and credit data both represent claims on the same companies, but the market conventions around how those companies are identified, how their instruments are described, and how information about them is distributed are entirely different. Any system that tries to model both has to resist the temptation to unify prematurely. The Company node isn't an equity node with credit data bolted on, and it isn't a credit node with an equity ticker attached. It's a legal entity node, and the equity and credit representations hang off it as separate subgraphs.

The dedup work also forced a conversation about what "canonical" means when you have conflicting data from multiple sources. The heuristic I landed on — prefer the node with the most attached research, prefer equity ISINs for primary_isin — is defensible but not perfect. There are edge cases. There will always be edge cases. The script is in the repo and it will run again when the next batch of messy data arrives.

What I'd do differently: define the BondIssue node as a first-class entity from day one, before any credit data touches the graph. Don't let primary_isin be ambiguous for a single commit cycle. Identifier discipline is the kind of thing that feels like over-engineering until the moment you're staring at 127 duplicate nodes at midnight.

The graph now knows about bonds, news, and a proper credit universe. The context builder can traverse all of it and hand an LLM something genuinely useful to reason about. The scaffolding is there.

What it lacks is urgency. A static snapshot of a company's bonds and research notes is valuable, but trading floors run on now — price moves, covenant triggers, breaking news. The next chapter is about making the platform feel alive: real-time event ingestion, the question of what the graph should forget, and whether a graph database is actually the right tool for anything that moves at market speed.

What's been your experience expanding a data model you thought was solid into a messier adjacent domain? Did you rebuild from scratch, or patch and tag your way through like I did?

Part 3 of 7 in the series "Building a research hive mind"

Choosing a graph over a database was the easy part

Leiv Eriksson — Thu, 12 Mar 2026 00:55:46 +0000

Designing the node-and-edge skeleton that would have to hold everything

The moment you decide to model your data as a graph, you are betting that relationships are more important than records — and you can't easily change your mind later. I made that bet on a Tuesday morning with a whiteboard marker in one hand and a half-finished coffee in the other, sketching nodes and edges for a system that didn't exist yet. The schema felt elegant. It felt obvious, even. And that feeling — the dangerous one, the one that makes you commit — is exactly when the doubt sets in. What if the thing that feels obvious now is the thing you'll be refactoring in six weeks, cursing yourself for not seeing the edge case that was always there?

It wasn't six weeks. It was four days.

Where we are

In the first chapter, I described the research desk's memory problem: analyst notes scattered across email threads, earnings prep that lived in someone's head, no clean way to ask "what do we know about this company right now?" The answer we kept circling back to was not a better database. It was a different kind of database — one that could model not just entities, but the tissue connecting them.

That chapter ended with a vague architectural direction. This one is where we had to make it real.

The project that I hope to build is basically a digital twin for the research division — a living graph of every company under coverage, every analyst who covers it, every note ever written, every filing pulled from EDGAR, every material event captured from exchange feeds. Not a data warehouse. Not a CRM. Something that can answer questions like: What has changed about this issuer in the last 30 days, and who on the team should care?

The problem

The first decision was the one that felt least like a decision: should this be relational or graph?

I asked the AI what I should do. Nobrainer it said, Postgres. It seemed to know it better, relying on endless examples online. The ecosystem is mature, the tooling is excellent, and when something goes wrong at 2am, Stack Overflow and Github training data means that the AI has a answer ready in a heartbeat. Choosing anything else seemed risky.

But the data we were modeling was fundamentally relational in the graph sense, not the table sense. A company has analysts. Analysts write notes. Notes reference events. Events trigger filings. Filings update estimates. Estimates change coverage posture. Every one of those connections is a first-class fact — not a foreign key you join through, but a relationship with its own properties and its own queryable meaning.

The moment you start drawing that on a whiteboard, a graph isn't exotic. It's just honest.

We evaluated two options seriously. Neo4j is the obvious choice — battle-tested, Cypher is expressive, the community is large. But we were building something that needed to run embedded, close to the application layer, without the operational overhead of managing a separate server process in the early stages. That pointed us toward an alternative, a embeddable graph database with Cypher support, columnar storage, and a Python API that felt like it was designed by people who had actually suffered through the alternatives.

The risk was real. The alternative was newer. Production references are fewer. Training data lacking. We were going to be among the early adopters in a financial context, which is exactly the kind of sentence that makes compliance teams nervous. Good thing I haven't told them about the project yet (but for now I'm working on publically available data ONLY).

Into the unknown

The schema came together fast — maybe too fast.

The core node types were clear from day one: Company, Analyst, Sector, ResearchNote, Filing, MaterialEvent, CoverageRecord, BondIssue, EstimateSnapshot. The edges were where the thinking happened. A COVERS relationship between Analyst and Company isn't just a link — it has a start date, a rating, a target price. A REFERENCES edge between a ResearchNote and a MaterialEvent carries context about why that event mattered to that note.

Here's a simplified version of how node types were declared in Python, binding the schema definition directly to the graph client:

# graph/schema/nodes.py (illustrative excerpt)

NODE_DEFINITIONS = {
    "Company": {
        "ticker": "STRING",
        "isin": "STRING",
        "name": "STRING",
        "sector": "STRING",
        "market_cap": "DOUBLE",
        "last_updated": "TIMESTAMP",
    },
    "ResearchNote": {
        "note_id": "STRING",
        "title": "STRING",
        "published_date": "DATE",
        "sentiment": "STRING",
        "word_count": "INT64",
    },
    "MaterialEvent": {
        "event_id": "STRING",
        "event_type": "STRING",
        "event_date": "TIMESTAMP",
        "headline": "STRING",
        "source": "STRING",
    },
}

The bootstrap script would walk these definitions and issue the equivalent CREATE NODE TABLE calls against the graph DB. Clean. Declarative. And — critically — easy to modify before anything real was written to the graph.

The FastAPI layer went up in parallel, and this is where we made a choice I'm still glad about: the API routers never touched the graph directly. From day one, all graph access was routed through service classes — CompanyService, and later GraphQueryService — that translated between HTTP semantics and Cypher. The routers asked questions in domain language. The services answered in graph language.

# api/routers/companies.py (illustrative pattern)

@router.get("/{ticker}/snapshot")
async def get_company_snapshot(
    ticker: str,
    service: CompanyService = Depends(get_company_service),
):
    snapshot = await service.get_full_snapshot(ticker)
    if not snapshot:
        raise HTTPException(status_code=404, detail="Company not found")
    return snapshot

The seam between router and service sounds obvious in retrospect. At the time, under pressure to get something queryable, it required active discipline to not just inline the Cypher into the route handler and move on.

The first real failure came from the connectors. We had live integrations running against SEC EDGAR and stock exchange news sites, plus stub connectors for Bloomberg and FactSet running in mock mode. The data coming back was messier than the schema expected — companies with missing ISINs, events with ambiguous timestamps, filings that referenced entities not yet in the graph. The graph's strictness, which felt like a feature in the design phase, became a source of friction the moment real data arrived.

We spent quite some time writing transformer logic that could have been avoided but wasn't - because the real world doesn't normalize itself for you.

What worked

The first time I ran a traversal query against real data, I understood why people build graph databases.

The query was simple: give me every research note written about companies in a specific sector, ordered by date, with the analyst and any associated material events. In a relational model, that's three or four joins, and you're mentally tracking the join path the whole time. In Cypher, it reads almost like the question itself:

MATCH (a:Analyst)-[:AUTHORED]->(n:ResearchNote)-[:COVERS]->(c:Company)-[:IN_SECTOR]->(s:Sector)
OPTIONAL MATCH (n)-[:REFERENCES]->(e:MaterialEvent)
WHERE s.name = $sector_name
RETURN a.name, n.title, n.published_date, c.ticker, e.headline
ORDER BY n.published_date DESC

There's no impedance mismatch. The shape of the query matches the shape of the question. For a system where new question types arrive every week from analysts who didn't write the code, that matters enormously.

The GraphQueryService — introduced in the second commit — was where the architecture paid off properly. Instead of 23 inline Cypher queries scattered across five API routers, we centralized everything into typed methods with clear contracts. The routers became thin. The service became testable. And when an analyst asked for a query type we hadn't anticipated, we added one method in one place.

The agents came online against this foundation, and that's when the system started feeling like something. The company snapshot agent could traverse the graph and produce a structured summary of everything known about an issuer. The earnings prep agent could pull analyst coverage history, recent notes, and upcoming filing dates in a single coherent pass. The report drafting agent had something real to work with.

The Prefect flow layer, added four days later, gave the pipelines retry logic and observability without requiring us to rewrite anything fundamental. The graph contract held.

What this changed

The graph bet forced an ontology conversation we would have had to have anyway — we just had it before writing a single line of application logic, which is the right time.

If you're considering a graph database for a production system, the operational concern is real but manageable. The harder thing is the schema: once analysts and pipelines are writing to the graph, changing a node type is a migration, not a refactor. We learned to be conservative about what became a node versus what stayed as a property. Events became nodes. Statuses stayed as properties. That line matters.

I'd also instrument the query layer earlier. We added logging to GraphQueryService in the second commit, but we should have had it from the first bootstrap. You want to know which traversals are expensive before something is slow in production, not after.

The seam between data connectors and graph writers — the transformer pipeline — is where the real complexity lives. Not in the graph itself.

Signpost

The foundation is in place: a typed graph, a service layer, a set of agents that can actually reason over connected data. What comes next is the part everyone underestimates — pulling in credit data alongside equity data and discovering that the two worlds have almost nothing in common except the company name. Bonds don't have tickers. Covenants don't have analogues in equity filings. And the graph that felt complete on Tuesday morning turns out to have a very significant gap.

How do you model instruments that fundamentally resist being modeled the same way — without fracturing your schema into two separate systems that can't talk to each other?

Part 2 of 7 in the series "Building a research hive mind"

The research desk has a memory problem

Leiv Eriksson — Mon, 09 Mar 2026 22:49:00 +0000

Why a securities firm needed a brain, not another dashboard

An analyst leans across the desk and asks: "What's our current stance on XYZ Inc — the one that filed something last quarter?" Thirty seconds, maybe a minute at most, is how long this should take. But the guy that covered the name had quit. Instead, what follows is a small, painful expedition. Someone opens a Bloomberg terminal. Someone else searches their inbox for a coverage note that was definitely emailed around. A third person remembers a conversation from an earnings call but can't locate the transcript. Twelve browser tabs and twenty-five minutes later, the picture assembles itself from fragments. The answer was always there. It was just distributed across four systems, two inboxes, and one analyst's increasingly unreliable memory. That moment — that unnecessary expedition — is where this project begins.

The beginning

I have worked as a research analyst my entire career. Never written a line of python, but always with a focus on building infrastructure to solve for friction in my everyday tasks. Peer comps are cumbersome - build spreadsheets that pull from Bloomberg and our own estimate databases. Updating powerpoints sucks - build chart packs that can be automatically refreshed (but with external third party EXPENSIVE plug ins since excel and powerpoint hate each other on a biblical level). But context gathering, context switching and in general working with a complete mess of information at all times, seemed like part of the job. I simply did not have time nor the knowledge to build a universal research tool that gave me everything I wanted, when I wanted it. That is, until the last iteration of AI coding tools surfaced.

Where we are

This is the first dispatch in a seven-part series about building a research intelligence platform for a securities firm. I'm writing it as the foundation is being laid, a single enormous commit landing with 79 files and north of forty thousand lines of code — everything from graph schema definitions to live data connectors to the first generation of AI agents.

I'll document the decisions as honestly as I can. The architecture choices, the wrong turns, the moments where a clean idea collided with a messy reality. This first chapter doesn't touch much code. It's about the problem itself, and why the problem turned out to be more interesting — and more stubborn — than it first appeared.

The problem

Research analysts at a securities firm operate under a specific kind of cognitive load that is almost invisible until you start mapping it. They carry coverage universes in their heads. They know which companies are approaching earnings season. They remember that a particular issuer's CFO said something cautious on a call six months ago. They recall a ratings change that happened before a junior colleague joined the team.

This knowledge is real and valuable. It is also almost entirely unstructured.

The firm had tools, of course. Terminal access for market data. A distribution platform for outbound research notes. Swimming in stock notifications from a plethora of different sites. Bloomberg, Factset, you name it. The data existed and we had it all. What didn't exist was any connective tissue between it — no way to ask a question that crossed system boundaries, no way to surface what the firm collectively knew about a company at a given moment.

The invisible cost isn't any single wasted lookup. It's the compounding drag of every analyst rebuilding context from scratch, every time, for every question.

What ratings changes has this analyst published in the last six months? What material events has this issuer filed since our last note? What were the key estimate revisions going into the last earnings cycle? Every one of these questions had an answer. None of them had a fast path to it, and the paths that did exist were long and painful.

The temptation, at this point, is to reach for a SaaS tool. Notion, Confluence, a better intranet, a fancier search layer over the existing systems. I gave that route genuine consideration. The problem is that knowledge management tools are designed around documents and pages — human-authored artifacts that someone has already synthesized. What we were dealing with was something different: a dense web of relationships between entities. Companies. Analysts. Ratings. Events. Filings. Notes. Bonds. The meaning lived not in any single document but in the connections between things.

A search index would tell you what documents mention a company. It wouldn't tell you that this company's coverage analyst changed eight months ago, that coverage intensity has dropped since the change, that the last three notes were all published within a week of an earnings filing, and that a material event landed last Tuesday that nobody has formally reacted to yet. That's not a search problem. That's a graph problem.

Into the unknown

I want to be honest about the vertigo of this moment. Deciding to build a custom graph-backed platform rather than assemble something from existing parts is not a modest commitment. It means owning the schema. It means owning the ingestion pipelines. It means owning the query layer, the agent layer, the API, the interface. It means that when something breaks at 7:45am before a market open, the person on call is you. I get physically sick of thinking of the responsibility I could end up with, if this actually makes it all the way to production.

I went looking for evidence that this was the right call rather than an elaborate form of scope creep. I studied what Palantir built for institutional knowledge management. I looked at how Cognite approaches industrial knowledge graphs in the energy sector. What was so genious about Databricks? I read everything I could find about how these firms used graph-based and other approaches to make sense of data, and more importantly the connections between the data.

What I kept returning to was a structural observation: financial research knowledge is fundamentally relational, and relational knowledge degrades when you store it in flat structures. A research note isn't just a document. It's a relationship between an analyst, a company, a rating, a date, a set of estimates, and a market context. Strip away those relationships and you have a PDF. Keep them and you have something you can reason about.

The early schema sketches were humbling. My first attempt at modeling the domain felt clean — companies, analysts, notes, events — until I started trying to answer real questions against it. The schema didn't know the difference between an analyst covering a company and an analyst having covered a company. It couldn't represent the difference between a rating that was current and one that had been superseded. Temporal validity is genuinely hard to model, and I'd underestimated it.

I also underestimated how much the data connectors would teach me about the domain. Building the integration with regulatory filing feeds forced me to understand what "material event" actually means in practice versus in theory. The filings integration surfaced the gap between how events are categorized and how they're actually used by analysts.

Early naive approach — the code that never shipped

# Flattening event data into a document store
def store_event(event: dict) -> None:
    doc = {
        "company": event["issuer_name"],
        "date": event["published"],
        "type": event["category"],
        "text": event["body"]
    }
    search_index.add(doc)

# The problem: we've lost the relationship between the event
# and the company's coverage record, analyst assignment,
# and any notes published in response to it.
# Querying "what did we do after this event?" becomes impossible.

That code never made it into the real system. But writing it clarified exactly why it couldn't.

What worked

The decision that unlocked everything was committing to graph-native modeling from the start, rather than treating the graph as a layer on top of something relational.

The node types that eventually stabilised — Company, Analyst, Sector, CoverageRecord, ResearchNote, MaterialEvent, Filing, BondIssue, EstimateSnapshot — weren't designed top-down. They emerged from asking "what questions do analysts actually ask?" and working backwards. Every node type represents a thing that analysts reason about. Every edge type represents a relationship that changes the answer to a question.

# Excerpt from graph/schema/nodes.py — illustrating the principle
# A CoverageRecord isn't just a link between Analyst and Company.
# It carries its own temporal properties and state.

@dataclass
class CoverageRecord:
    analyst_id: str
    company_id: str
    rating: str
    target_price: float | None
    currency: str
    coverage_start: date
    coverage_end: date | None      # None = currently active
    is_primary: bool
    last_note_date: date | None

The coverage_end field looks trivial. It took three schema iterations to get there. Without it, you cannot answer "who covered this company before the current analyst?" Without it, you cannot audit continuity of coverage. Without it, you cannot detect that a company in your universe has gone unreferenced for ninety days.

The schema is an argument about what matters. Every field is a claim that this piece of information is worth carrying forward. Getting the schema right — genuinely right — turned out to be the most intellectually demanding part of the foundation phase.

The agent architecture followed a similar principle. Rather than a single general-purpose assistant, the system needed specialists: a company snapshot agent that could assemble a complete current picture, an earnings preparation agent that could pull together everything relevant before a call, a material event monitor that watched for regulatory filings and surfaced them to the right analyst. Each agent is narrow. The graph is what makes the narrowness sufficient — because every agent has access to the full relational context, a focused question gets a rich answer.

What this changed

The commit that landed this foundation — 79 files, forty-thousand-plus lines — is almost certainly the densest single push this project will ever see. Normally that's a warning sign. In this case it reflects something real: you can't build half a knowledge graph. The schema, the connectors, the writers, the query layer — they form a system. They only work together.

What I'd do differently is start the data connector work earlier, and treat it as domain research rather than engineering. Every connector teaches you something about the data it touches. The bond data integration changed my understanding of how the fixed-income side of the coverage universe needed to be modeled. I'd have designed a better initial schema if I'd done that integration first.

The deeper lesson is that knowledge infrastructure is never purely a technical problem. It's a problem about how people think, what they need to know, and when they need to know it. The right architecture is the one that mirrors the actual cognitive work — not the one that's technically elegant in isolation.

The dashboard, the agents, the API — those are expressions of an idea about what the research desk could become. The graph is the idea itself.

Next up: the graph database selection process looked like a technical decision. It turned out to be a question about operational reality — and the answer surprised me.

What's the most valuable piece of knowledge at your organisation that currently lives only in someone's head? And what would it take to change that?

Follow along — Part 2 drops soon

Part 1 of 7 in the series "Building a research hive mind"