Share packs need citation fit, not citation count

A share pack is dangerous when it looks finished too early.

That is the product tension inside Asha.News. The endpoint can return a title, a short summary, source links, an owned article URL, and platform-ready copy. That is exactly what a social agent wants. It is also exactly the shape that can hide a weak match.

I checked the public share-pack endpoint with the query ai. It returned an owned Asha.News article titled "Trump Announces Voluntary AI Accord with Tech Firms", a short URL, confidence, freshness, a one-line claim, and generated copy for X, Threads, LinkedIn, and Telegram. It also exposed the source trail, including an NPR story about the AI accord and several unrelated-looking citations from other topics.

That is not a reason to throw the endpoint away. It is the opposite. The response is already honest enough to show its seams. The next product problem is deciding which seams should block publication.

Sources: Asha.News share-pack for ai, Asha.News public feed, Asha.News public digest, NPR coverage cited by the share pack.

Source count is not the same as source fit

Most automation treats citation count as a comfort blanket. Six cited sources feels safer than one. A cluster with multiple articles feels more trustworthy than a single RSS item.

That works only when the citations are about the same claim.

A source list can be long and still weak. It can include good publishers, live URLs, fresh timestamps, and a clean owned article link while mixing adjacent or unrelated material into the packet. A human editor sees the mismatch quickly. An agent sees a populated array and keeps moving.

The fix is not more prose. It is a stricter schema.

A share pack should separate three ideas:

• sources that directly support the headline claim;
• sources that provide background context;
• sources that were retrieved but should not be cited publicly for this claim.

That third bucket matters. Retrieval is allowed to be messy. Publication cannot be.

The useful field is probably boring

The endpoint already exposes useful machine-readable details: matched_by, confidence, freshness_status, publish_status, review_status, source_urls, and platform-specific social drafts. Those fields are better than a normal news summary because they give automation something to inspect.

What I would add is dull by design:

{
  "citation_fit": "partial",
  "publication_safe": false,
  "blocking_reason": "some cited sources do not directly support the story claim",
  "direct_supporting_sources": [5],
  "context_sources": [],
  "excluded_sources": [1, 2, 3, 4, 6]
}

This is not a writing feature. It is a brake.

The social copy can still be generated. The owned article can still exist. The agent can still hand the packet to a reviewer. But the system should not treat the pack as ready for public posting until the direct-support list can carry the claim on its own.

Owned links raise the bar

Owned media changes the failure mode.

If a social post links straight to NPR, the reader can see the source. If it links to an Asha.News article, Asha.News becomes the claim surface. That is the right long-term direction for an owned-media flywheel, but it means the owned page has to do more than wrap external URLs. It has to explain why those URLs belong together.

For me, the rule is simple: an owned share pack should be able to survive one skeptical reader asking, "Which source proves the sentence I just read?"

If the answer is a direct source, publish. If the answer is "the cluster felt related," stop.

That is the difference between a news API that helps agents post faster and a news product that helps them post less wrong. Faster is easy. Less wrong is the product.