We introduce PAST-TIDE, our stance detection system addressing both subtasks of the StanceNakba Shared Task at NakbaNLP@LREC-COLING 2026. The main idea is statement tuning. We redefine stance as cloze-style masked language modeling (MLM), letting a verbalizer map label words to stance categories through the pre-trained MLM head rather than appending a randomly initialized classification head. We complement this with prototypical contrastive learning, which uses learnable class prototypes for batch-size independent contrastive training, and topic-conditional layer normalization for cross-topic Arabic stance detection. PAST-TIDE achieves macro-F1 scores of 0.75 for Subtask A and 0.74 for Subtask B on the official leaderboard, indicating that minimal architectural additions to a pre-trained model can remain competitive in low-resource settings.
Alex: Welcome to another episode of ResearchPod. Today, we're looking at a system called PAST-TIDE, designed to identify a person's stance—their position for or against a specific topic—in short text.
Sam: So the core challenge here is figuring out whether someone supports or opposes a topic, but without many examples to train the computer on?
Alex: Exactly. Standard methods for this task often fail when data is scarce. The reason is that they typically bolt on a brand-new decision-making layer to the model—and that layer has almost nothing to learn from when examples are few.
Sam: So the researchers sidestep that problem by using what the model already knows, rather than teaching it something new from scratch?
Alex: That's the central idea. Instead of adding new machinery, they reframe the whole task as a fill-in-the-blank exercise. Imagine asking the model to complete the sentence: "The author's stance is ___." The model already knows words like "support" or "against" from reading vast amounts of text, so it can fill that blank without needing a new layer trained from zero.
Sam: So you're not teaching the model a new skill—you're just asking it a question in a way that lets it use the skills it already has?
Alex: Precisely. They call this approach "statement tuning." It's a meaningful shift because it means the system can classify stance without any randomly initialized components that would need thousands of examples to become reliable.
Sam: But if the model is just filling in a blank, how does it know which words actually count as "support" versus "opposition"?
Alex: Good question. They use what they call a "verbalizer"—think of it as a small dictionary that maps the model's vocabulary onto the labels the researchers care about. So if the model predicts the word "pro" or "yes," the verbalizer translates that into the category "support." It's a bridge between the model's general language knowledge and the specific task at hand.
Sam: That's a neat solution. Does this approach hold up across different languages?
Alex: It does, though with an interesting wrinkle. They found that even when analyzing Arabic text, using English label words in the verbalizer worked well. The reason is that large language models develop a kind of shared internal map of concepts that cuts across languages—so "pro" in English still points the model in the right direction even when the surrounding text is Arabic.
Sam: You mentioned they also use something called "prototypical contrastive learning." Why is that necessary on top of the fill-in-the-blank method?
Alex: Even with the right prompts, the model can still drift—it might gradually lose track of what "support" looks like versus "opposition," especially when it's only seeing a handful of examples at a time. So they create three "prototypes," one for each stance category. Think of them as ideal, averaged-out examples of what support, opposition, and neutrality each look like. Every new sentence gets compared to these three anchors, and the model learns by asking: which anchor does this most closely resemble?
Sam: So the prototypes act as stable reference points that keep the model grounded, even when the training data is thin?
Alex: Exactly. Standard approaches compare items within a single batch of training data, which is unreliable if that batch is small—you might just happen to have a bad mix. Prototypes are always present regardless of batch size, so the model always has something solid to orient itself against.
Sam: They tested this on Arabic data covering multiple different topics. Did the model get confused between those topics—mixing up the language used for, say, refugees versus trade agreements?
Alex: That was a real concern. Different topics use different vocabulary and framing, so they added a technique called "topic-conditional layer normalization." In plain terms, it means the model generates a slightly different set of internal settings for each topic—like adjusting the lens on a camera depending on what you're photographing. This stops the model from blending the linguistic patterns of one debate into another.
Sam: So it's a topic-specific filter built into the model's internals. Did the authors flag any limitations to all of this?
Alex: They did. Because of limited computing resources, they couldn't run a fully controlled experiment that isolates exactly how much each individual component—the fill-in-the-blank framing, the prototypes, the topic filter—contributes on its own. Their results come from comparing different versions of the full system rather than cleanly separating each piece.
Sam: Right—if you change three things at once, it's hard to know which one is doing the heavy lifting.
Alex: That's a fair characterization of the limitation they acknowledge. What they can say is that the combined system performs competitively in low-resource settings, and the underlying logic—using what the model already knows rather than adding complexity—holds up across their tests.
Sam: So the practical takeaway is that when data is scarce, the smarter move is to ask better questions of the model you already have, rather than building a bigger, more complex one?
Alex: That's the implication the authors draw. And they suggest the logical next step is automating the selection of the best fill-in-the-blank words—rather than having researchers choose them manually—which could make these systems more effective and easier to deploy.
Sam: It's a useful reminder that sometimes a small change in how you frame a problem—shifting from "teach the model a new skill" to "ask it to use what it already knows"—can matter more than adding layers of new machinery.
Alex: And that's what makes this work worth paying attention to. By leaning on the knowledge already embedded in pre-trained models, they achieved competitive results with almost no new trainable parameters. It's a case where careful design compensated for a real data constraint.
Sam: A good example of working smarter with limited resources. Thanks for walking us through it, Alex.
Alex: My pleasure. Thanks for listening to ResearchPod.