u/farach

I have been working on foundryR, a development-version R package for using Microsoft Azure AI Foundry from dataframe-oriented workflows.

The main design choice is "dataframe in, dataframe out." The package returns tibbles for things that are otherwise awkward to keep inside R pipelines:

Azure AI Content Safety: moderation, groundedness, prompt-shield checks, protected material, blocklists
strict structured extraction using JSON Schema
embeddings and pairwise similarity
Batch and Files API workflows
Responses API calls, tools, stored agents, usage fields, and raw response capture
codebooks, agreement, consistency, and provenance helpers for annotation work

The docs are here:

https://farach.github.io/foundryR/?utm_source=reddit&utm_medium=community&utm_campaign=foundryr_launch

GitHub:

https://github.com/farach/foundryR

Install:

install.packages("pak")
pak::pak("farach/foundryR")

A small example of the package shape:

foundry_moderate("Thanks so much for your help, this was a great session.")
#&gt; # A tibble: 4 x 6
#&gt;   text category severity label blocklist_matches raw_response

It is not on CRAN yet, and some helpers wrap preview APIs. I would be grateful for feedback from people who use R with Azure AI Foundry: where is setup confusing, what output shapes are missing, and what should be documented before a broader release?

I maintain onet2r, an R package for working with O*NET data, and just shipped a larger update (the 0.4 line). The problem it tries to handle: O*NET is useful but is not a clean longitudinal panel. The Web Services API serves the current release. Historical comparisons need the archived database files, O*NET-SOC taxonomy bridges, and some care about whether a changed value is a real update, a stale carryforward, a transition row, a suppressed estimate, or a taxonomy seam. What it does: - reads archived O*NET releases into one normalized panel - keeps native 8-digit O*NET-SOC codes and derives 6-digit SOC codes for joins - reconciles two releases and flags rows that are not safely comparable - validates a user-supplied task or occupation measure against a pinned release - rolls task scores up to occupations using O*NET task ratings - builds OEWS or PUMS employment weight panels with coverage and provenance - decomposes aggregate change into within, between, interaction, and unclassified Docs with runnable examples: https://farach.github.io/onet2r/ GitHub: https://github.com/farach/onet2r Blog: https://workforcefutures.net/blog/onet2r-release/ The hardest design question, and where I would value opinions: how much comparability checking should be automatic versus left visible for the analyst? Right now I lean toward visible, with explicit flags, because a clean-looking number hides too much. Curious whether people who use O*NET historically agree.

foundryR: tibble workflows for Azure AI Foundry from R

onet2r: archived O*NET releases, OEWS/PUMS weights, and reproducible occupation measures in R