[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-75659":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":16,"stars30d":17,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":19,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":22,"hasPages":22,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":44,"readmeContent":45,"aiSummary":46,"trendingCount":16,"starSnapshotCount":16,"syncStatus":47,"lastSyncTime":48,"discoverSource":49},75659,"OpenFoundry","DioCrafts\u002FOpenFoundry","DioCrafts","🏭 The open-source Palantir Foundry alternative. Connect any data source, build ontologies, create pipelines, visualize with dashboards, and make AI-powered decisions. Self-hosted.","",null,"Go",234,136,9,27,0,212,56.41,"GNU Affero General Public License v3.0",false,"main",true,[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"ai","analytics","artificial-intelligence","business-intelligence","data-engineering","data-pipelines","data-visualization","golang","hacktoberfest","low-code","microservices","ontology","open-source","osint","palantir","palantir-alternative","palantir-foundry","palantir-inspired","react","self-hosted","2026-06-12 04:01:18","\u003Cdiv align=\"center\">\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fopenfoundry\u002Fopenfoundry-go\">\n    \u003Cimg src=\"images\u002Flogo.png\" alt=\"OpenFoundry\" width=\"420\" \u002F>\n  \u003C\u002Fa>\n\n\n  **The Open-Source Data Operating System**\n\n  An open, cloud-native operational data platform for building data products with datasets, ontologies, applications, AI\u002FML, governance, and observability from one monorepo.\n\n  \u003Cp align=\"center\">\n    \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fopenfoundry\u002Fopenfoundry-go\u002Factions\u002Fworkflows\u002Fopenfoundry-go.yml\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Factions\u002Fworkflow\u002Fstatus\u002Fopenfoundry\u002Fopenfoundry-go\u002Fopenfoundry-go.yml?branch=main&style=for-the-badge&label=Go%20CI\" alt=\"Go CI\" \u002F>\u003C\u002Fa>\n    \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fopenfoundry\u002Fopenfoundry-go\u002Factions\u002Fworkflows\u002Fci-frontend.yml\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Factions\u002Fworkflow\u002Fstatus\u002Fopenfoundry\u002Fopenfoundry-go\u002Fci-frontend.yml?branch=main&style=for-the-badge&label=Frontend%20CI\" alt=\"Frontend CI\" \u002F>\u003C\u002Fa>\n    \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fopenfoundry\u002Fopenfoundry-go\u002Factions\u002Fworkflows\u002Fproto-check.yml\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Factions\u002Fworkflow\u002Fstatus\u002Fopenfoundry\u002Fopenfoundry-go\u002Fproto-check.yml?branch=main&style=for-the-badge&label=Proto%20Check\" alt=\"Proto Check\" \u002F>\u003C\u002Fa>\n    \u003Ca href=\"LICENSE\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-AGPL--3.0--only-blue.svg?style=for-the-badge\" alt=\"AGPL-3.0-only license\" \u002F>\u003C\u002Fa>\n  \u003C\u002Fp>\n\n  [Documentation](docs\u002F) · [Architecture](ARCHITECTURE.md) · [Contributing](CONTRIBUTING.md) · [Security](SECURITY.md) · [Issues](https:\u002F\u002Fgithub.com\u002Fopenfoundry\u002Fopenfoundry-go\u002Fissues)\n\u003C\u002Fdiv>\n\n---\n\nOpenFoundry is an open-source operational data platform inspired by the capability model of Palantir Foundry, implemented as auditable, extensible software. It combines **50 service directories**, **36 shared libraries**, Protobuf\u002FOpenAPI contracts, generated SDKs, a **React 19 + Vite + TypeScript** web console, and declarative infrastructure for Kubernetes.\n\nThe goal is to provide a reproducible foundation for teams that need to connect sources, version datasets, model an ontology, expose APIs, automate workflows, govern access, and operate analytical or AI workloads with end-to-end traceability.\n\n> **Working with this codebase as an AI agent?** Start at [`CLAUDE.md`](CLAUDE.md). It is the canonical onboarding guide for commands, conventions, security-critical zones, and what not to read by default.\n\n## Features & Status\n\n- **Cloud-native architecture:** small Go services, one entrypoint per service, and delivery through Helm, ArgoCD, and Terraform.\n- **Ontology at the core:** object types, actions, functions, object views, lineage, and stable contracts for building applications on operational data.\n- **Contracts first:** Protobuf as the source of truth, generated OpenAPI, and synchronized TypeScript, Python, and Java SDKs.\n- **Integrated governance:** authentication, authorization, Cedar policies, audit, tenancy, SSO\u002FMFA, and egress controls.\n- **Observability by default:** `\u002Fhealthz`, `\u002Fmetrics`, Prometheus, Grafana, Mimir, structured logs, and OTel traces.\n- **Developer platform:** CLI tooling, SDK generation, service templates, VitePress docs, and unit\u002Fintegration test paths.\n\n| Capability | Status | Capability | Status |\n| :-- | :-- | :-- | :-- |\n| **Datasets & versioning** | ✅ Available | **Ontology services** | ✅ Available |\n| **React web console** | ✅ Available | **Generated SDKs** | ✅ Available |\n| **Protobuf\u002FOpenAPI contracts** | ✅ Available | **AuthN\u002FAuthZ foundations** | ✅ Available |\n| **Observability stack** | ✅ Available | **Helm\u002FArgoCD delivery** | ✅ Available |\n| **Kafka\u002FNATS integrations** | ✅ Available | **Lakehouse\u002FIceberg paths** | Under active development |\n| **AI\u002Fagent runtime services** | Under active development | **Production hardening** | In progress |\n\n## OpenFoundry vs closed data platforms\n\n| Area | OpenFoundry | Closed platforms |\n| :-- | :-- | :-- |\n| **Control** | Auditable code, contracts, and infrastructure in one monorepo. | Strong provider dependency and less implementation visibility. |\n| **Extensibility** | Services, libraries, SDKs, and docs can evolve with your needs. | Extensions are limited by external APIs and vendor roadmaps. |\n| **Deployment** | Kubernetes, Helm, ArgoCD, Terraform, and Compose for reproducible environments. | Usually SaaS or managed deployments with less operational control. |\n| **Governance** | Policies, audit, and tenancy live beside the platform code. | Governance is coupled to the product and its commercial boundaries. |\n| **Developer workflow** | Standard Go, TypeScript, Python, Java, Protobuf, and Makefile workflows. | Proprietary tooling or local workflows that are harder to automate. |\n\n## Quickstart\n\n### 1. Clone the repository\n\n```sh\ngit clone https:\u002F\u002Fgithub.com\u002Fopenfoundry\u002Fopenfoundry-go.git\ncd openfoundry-go\n```\n\n### 2. Install development tools\n\n```sh\nmake tools\n```\n\nThis installs the Go tools used by the monorepo into `.\u002Fbin`, including `buf`, `golangci-lint`, `sqlc`, and `gofumpt`.\n\n### 3. Run the main local gate\n\n```sh\nmake ci\n```\n\n`make ci` runs tidy, vet, lint, contract checks, and unit tests. For faster iteration, use:\n\n```sh\nmake test\nmake build\nmake contracts-check\n```\n\n### 4. Start the frontend\n\n```sh\npnpm install\npnpm --filter @open-foundry\u002Fweb dev\n```\n\nThe web application lives in [`apps\u002Fweb\u002F`](apps\u002Fweb\u002F) and uses React 19, Vite, and TypeScript.\n\n### 5. Start local dependencies with Compose\n\n```sh\ndocker compose -f infra\u002Fcompose\u002Fdocker-compose.yml up -d\n```\n\nFor development, there is also:\n\n```sh\ndocker compose -f infra\u002Fcompose\u002Fdocker-compose.dev.yml up -d\n```\n\n### 6. Deploy to Kubernetes\n\n```sh\nmake gitops-bootstrap\nmake gitops-status\n```\n\nDelivery assets live in [`infra\u002F`](infra\u002F): Helm charts, ArgoCD apps, Terraform, Compose, and operational runbooks.\n\n## Repository layout\n\n```text\nopenfoundry-go\u002F\n├── apps\u002Fweb\u002F         React 19 + Vite + TypeScript frontend\n├── services\u002F         Go microservices; copy docs\u002Ftemplates\u002Fservice-skeleton\u002F for new services\n├── libs\u002F             Shared Go packages for auth, observability, kernels and more\n├── proto\u002F            Protobuf source of truth; Go generated into libs\u002Fproto-gen\u002F\n├── sdks\u002F             Generated TypeScript, Python and Java SDKs\n├── infra\u002F            Helm, ArgoCD, Terraform, Compose and operational runbooks\n├── docs\u002F             VitePress capability-oriented documentation site\n├── tools\u002F            CLIs and lint\u002Fhelper tools\n├── images\u002F           Project branding assets, including this README logo\n├── go.mod            Single Go module for the entire monorepo\n└── Makefile          Canonical local task runner\n```\n\nPer-service shape:\n\n```text\nservices\u002F\u003Csvc>\u002F\n  cmd\u002F\u003Csvc>\u002Fmain.go          entrypoint\n  internal\u002Fserver\u002F           chi router (\u002Fhealthz, \u002Fmetrics, \u002Fapi)\n  internal\u002Fhandlers\u002F         HTTP handlers\n  internal\u002Fdomain\u002F           pure logic\n  internal\u002Frepo\u002F             data access, sqlc-generated when relevant\n  internal\u002Frepo\u002Fmigrations\u002F  goose-style SQL migrations\n  internal\u002Fmodels\u002F           wire types\n  internal\u002Fconfig\u002F           koanf-backed config\n```\n\n## Why a single Go module?\n\nOpenFoundry uses a single Go module (`go.mod` at the root) instead of a multi-module `go.work` setup because it:\n\n- Keeps `libs\u002F` and `services\u002F` synchronized without version drift.\n- Simplifies dependency resolution, caching, and builds.\n- Makes contract generation and compatibility tests more direct.\n- Follows a familiar pattern for large infrastructure monorepos.\n\nSplitting specific services into their own modules remains possible if the project needs it.\n\n## Day-to-day commands\n\nRun these commands from the repository root:\n\n```sh\nmake help              # list available targets\nmake tools             # install tools into .\u002Fbin\nmake ci                # tidy + vet + lint + contracts-check + test\nmake test              # unit tests with race detector and coverage\nmake test-integration  # tests with the integration build tag; requires Docker\nmake gen               # regenerate proto Go, sqlc, OpenAPI, and SDKs\nmake contracts-check   # verify OpenAPI and SDK drift\nmake build             # compile all packages\nmake build-services    # compile one binary per service into .\u002Fbin\u002F\nmake lint              # golangci-lint\nmake fmt               # gofumpt + gci\n```\n\nFrontend:\n\n```sh\npnpm --filter @open-foundry\u002Fweb dev\npnpm --filter @open-foundry\u002Fweb check\npnpm --filter @open-foundry\u002Fweb test\n```\n\n## Documentation\n\n- [`docs\u002F`](docs\u002F) — capability-oriented technical documentation.\n- [`docs\u002Findex.md`](docs\u002Findex.md) — VitePress site entrypoint.\n- [`ARCHITECTURE.md`](ARCHITECTURE.md) — high-level architecture overview.\n- [`docs\u002Farchitecture\u002Fadr\u002F`](docs\u002Farchitecture\u002Fadr\u002F) — dated architectural decisions.\n- [`CLAUDE.md`](CLAUDE.md) — concise onboarding for AI agents.\n- [`CONTRIBUTING.md`](CONTRIBUTING.md) — PR process, RFC requirements, and DCO policy.\n- [`SECURITY.md`](SECURITY.md) — how to report vulnerabilities.\n\n## Wire-compatibility invariants\n\nSome contracts are pinned by golden tests and must not change without an explicit migration:\n\n- `\u002Fhealthz` payload shape (`status`, `service`, `version`, `timestamp`).\n- JWT claim names and JSON tags.\n- Resource RID format and minting: `ri.\u003Cservice>.\u003Cinstance>.\u003Ctype>.\u003Cuuid>` for platform-minted resources; `libs\u002Fcore-models\u002Frid` owns parsing, UUIDv7 minting, and registry-reservation collision handling.\n- Resource type registry: `libs\u002Fcore-models\u002Fresource` is the canonical registry for display names, owning services, icons, actions, RID namespace mapping, open-app URLs, and unknown-type placeholders.\n- Compass project resource: `tenancy-organizations-service` owns the stable project `rid`, parent `space_rid`, organization\u002Fmarking RIDs, default queue RID, resource-level grant toggle, and per-role policy payload.\n- Compass folder resource: `tenancy-organizations-service` owns stable folder `rid` values, project\u002Fparent\u002Fspace RID projection, folder trash status, and inheritance from project policies with folder-scope grant overrides.\n- Compass move\u002Frename: workspace operations may update project\u002Ffolder parentage, display names, slugs, and derived breadcrumbs, but must not mutate resource RIDs; cross-project folder moves require explicit access-policy and marking confirmations.\n- Compass search index: `tenancy-organizations-service` maintains `compass_resource_search_index` entries for project\u002Ffolder RIDs and long-text catalog sources such as descriptions, READMEs, ontology object\u002Fproperty descriptions, code repository READMEs, and dashboard descriptions. Writes emit `compass.resource.search.updated.v1` outbox events on create\u002Fupdate\u002Fmove\u002Ftrash\u002Frestore\u002Fpurge instead of relying on table polling.\n- Compass search API: `GET \u002Fapi\u002Fv1\u002Fcompass\u002Fsearch` (no current edge-gateway route; handler-level\u002Froadmap surface until `router_table.go` adds a branch) is permission-aware, supports `q`, `type`, `project`, `owner`, repeated `marking`, `modified`, `limit`, and `cursor`, returns highlighted snippets and facets for type\u002Fproject\u002Fowner\u002Fmarking\u002Flast-modified buckets, and paginates by opaque cursor over text score, last modified time, and RID.\n- Compass search UI shell: `apps\u002Fweb` route `\u002Fsearch` combines ontology search with the handler-level Compass search surface (`GET \u002Fapi\u002Fv1\u002Fcompass\u002Fsearch` has no current edge-gateway route), keeps the `Cmd\u002FCtrl+J` global search shell, loads jump-to recents\u002Ffavorites, displays marking badges and snippet highlights, renders resource facets in the sidebar, and derives resource \"Open with\" actions from the frontend Compass resource type registry.\n- Compass saved searches: `compass_saved_searches` stores per-user named Quicksearch\u002FData Catalog queries with tab, type, project, owner, marking, and last-modified filters; `\u002Fapi\u002Fv1\u002Fworkspace\u002Fsaved-searches` lists\u002Fcreates\u002Fdeletes them for the search sidebar.\n- Compass recommendations: `GET \u002Fapi\u002Fv1\u002Fworkspace\u002Frecommendations` returns permission-filtered \"you might want to open\" resources scored from collaborator opens, the caller's recent opens, and explicit project follows stored in `compass_project_follows`; Quicksearch jump-to mode renders them beside favorites and recents.\n- Compass open-with menu: `apps\u002Fweb\u002Fsrc\u002Flib\u002Fcomponents\u002Fworkspace\u002FOpenWithMenu.tsx` is the shared registry-backed launcher for search results, project\u002Ffolder list views, and resource detail headers; targets resolve from immutable RIDs when present and retain an unknown-resource fallback.\n- Compass breadcrumbs: `apps\u002Fweb` uses the shared `ProjectBreadcrumb` for project\u002Ffolder paths, click-to-open navigation, and per-crumb copy-RID actions derived from stable project\u002Ffolder RIDs.\n- Compass trash workflow: project\u002Ffolder\u002Fresource-binding deletes are soft deletes with configurable `retention_days` (default 30), `purge_after` metadata, search-index trash\u002Frestore events, and folder restore fallback to the project root when the original parent path is gone.\n- Compass hard delete audit: permanent deletes are allowed after `purge_after` or by admin override, clean directly affected Compass surface rows, and emit marking-aware `compass.resource.purged` audit events with the dependent rows\u002Fresources affected by the purge.\n- Compass resource audit: create, move, rename, trash, restore, purge, share grant\u002Fupdate\u002Frevoke, and marking-change mutations emit marking-aware `compass.resource.*` events to `audit.events.v1`; `audit-compliance-service` owns the public `GET \u002Fapi\u002Fv1\u002Faudit\u002Fevents` route; `services\u002Faudit-sink` only consumes `audit.events.v1` into Iceberg for storage\u002Fexport pipelines.\n- Compass bulk operations: `POST \u002Fapi\u002Fv1\u002Fworkspace\u002Fresources\u002Fbatch` applies selected search\u002Ffolder rows as one preflighted move\u002Ftrash\u002Fshare batch, aborts before mutation when any row fails policy\u002Fconfirmation checks, and emits one `compass.resource.bulk_operation` audit event for the batch instead of per-row audit noise.\n- Compass reverse-reference graph: `compass_resource_references` stores directed `source depends on target` edges, the resource registry declares supported reference targets, and workspace APIs\u002FUI expose `depends_on` \u002F `used_by` with move\u002Ftrash warnings.\n- Compass stable resource URLs: web routes and search\u002Fopen-with URLs identify resources by RID, with optional slug suffixes treated only as visual sugar so rename and move operations do not invalidate links.\n- Compass favorites: `user_favorites` is the synced per-user profile store for resource shortcuts; favorites have optional groups, stable display order, and a sidebar\u002Fsearch management UI backed by `\u002Fapi\u002Fv1\u002Fworkspace\u002Ffavorites`.\n- Compass recents: `resource_access_log` records per-user opens, while `\u002Fapi\u002Fv1\u002Fworkspace\u002Frecents` returns at most 50 visible resources by default, ordered by last-opened and filtered against current project visibility so revoked resources disappear.\n- Compass propagate view requirements: `tenancy-organizations-service` keeps Palantir's planned-deprecated setting as a legacy compatibility toggle. Project\u002Ffolder rows record whether propagation is enabled plus the permanent `disabled_at` marker; new folders and project resource bindings copy the inherited view-requirement marking snapshot on create, and parent policy changes enqueue `compass_view_requirement_propagation_jobs` to update existing descendants with progress reporting and `compass.view_requirements.propagated` audit events.\n- Dataset RID format: `ri.foundry.main.dataset.\u003Cuuid-v7>`.\n- Transaction state\u002Ftype tokens: `open|committed|aborted` and `snapshot|append|update|delete`.\n- Marking source and schema field type discriminators.\n- Media reference camelCase keys (`mediaSetRid`, `mediaItemRid`, `branch`, `schema`).\n\n## Getting help\n\n- Open a bug report or feature request in [GitHub Issues](https:\u002F\u002Fgithub.com\u002Fopenfoundry\u002Fopenfoundry-go\u002Fissues).\n- Review the documentation in [`docs\u002F`](docs\u002F) before changing services or contracts.\n- For new capabilities, start from the [`service skeleton`](docs\u002Ftemplates\u002Fservice-skeleton\u002F) and the existing ADRs.\n\n## Contributing\n\nContributions are welcome. See [`CONTRIBUTING.md`](CONTRIBUTING.md) for the PR process, RFC requirements, and DCO policy. Security reports follow [`SECURITY.md`](SECURITY.md).\n\n## License\n\nOpenFoundry is licensed under **AGPL-3.0-only**. See [`LICENSE`](LICENSE).\n\n","OpenFoundry 是一个开源的数据操作平台，旨在为构建数据产品提供云原生的解决方案。它支持连接任意数据源、构建本体、创建数据管道、通过仪表板进行可视化以及基于AI做出决策，并且可以自托管。项目采用Go语言编写，核心功能包括50个服务目录和36个共享库，使用Protobuf\u002FOpenAPI作为合同标准，生成SDK，并提供React 19 + Vite + TypeScript的Web控制台。适合需要连接不同数据源、版本化数据集、建模本体、暴露API、自动化工作流、治理访问及运行分析或AI工作负载的团队使用。此外，该平台还强调了集成治理与默认的可观测性。",2,"2026-05-18 11:12:21","CREATED_QUERY"]