# Learning Palantir Foundry 🚀 Action Types are what decisively separate Foundry from read-only BI. Approvals and assignments become safe, validated, structured writes. 📌 Title and Feature URL Title: アクションタイプ URL: 📝 Overview An Action Type defines a set of changes a user can apply to ontology objects, properties, and links in a single transaction. It encapsulates both the data modifications and any side effects triggered on submission, letting users think in terms of overall goals rather than individual property edits. 🔧 How It Works - Write-back to the ontology: when an action runs, all changes are committed to the ontology and reflected across every app. The latest object data, including user edits, is captured in the object type's write-back dataset. - Parameters and defaults: parameters standardize input, supporting default values, filtered dropdown results, and overrides. - Rules: define when and how an action executes, including object relationships and property constraints. - Submission criteria and validation: validation rules control execution eligibility and error handling before changes persist. - Action logs: a full audit trail of every executed action supports accountability and compliance. 🛠 Practical Usage - Run an "Assign Employee" style action that changes a role property, auto-creates a manager-employee link, and notifies stakeholders in one transaction. - Embed submission criteria like "only a director may submit amounts over 1M yen" as validation, replacing Excel-plus-email approvals with structured operations. - Reuse the same validation logic and workflow consistently across every user-facing app. 🎯 Use Cases - Standardize status changes, approvals, and assignments as permissioned, criteria-bound operations. - Let non-technical users safely execute multi-step changes spanning several objects. - Use the action log of every operation as an audit trail for internal controls. ⚠️ Caveats - Actions execute only after passing their validation rules, so submission-criteria design drives the quality of your controls. - Changes propagate immediately across the ontology and all apps, so do not leave rule and parameter design ambiguous. #PalantirFoundry# #Ontology#

# Learning Palantir Foundry 🚀 "How many screens do I need to open just to understand one customer?" Object Views answer that pain by bundling everything about a single object into one screen. 📌 Title and Feature URL Title: オブジェクトビュー URL: 📝 Overview Object Views act as the central hub for everything related to a specific object. They consolidate properties, linked objects, metrics and analytics, dashboards, and operational applications into a single unified interface. For example, an Airport object view can integrate flight timelines, delay-handling workflows, and location data in one place. In practice, an Object View becomes the daily "home screen" that frontline users open to start their work. 🔧 How It Works Object Views are highly configurable by builders: - They support multiple formats and sizes, so appearance and interaction patterns can be tailored to the task. - They combine properties (attributes), linked objects, metrics, analytics, and dashboards into one display. - They can be embedded throughout the platform wherever the object appears. - Configuration happens in the Ontology Manager under the "Object views" tab, and version tabs at the top let you switch between format variations. - Selecting "Edit views" opens the configuration editor or the underlying Workshop module. - The system also supports version management, panel variations, commenting, and Marketplace product integration. 🛠 Practical Usage - In Ontology Manager, select the target object type and use the "Object views" tab to preview and configure. - Lay out core information, related objects, operation history, and embedded dashboards so everything the team needs is on one screen. - Beyond viewing, embed action types so users can trigger status changes or assignments directly from the view. - Create multiple formats to show different layouts per role (for example, sales view vs. maintenance view). 🎯 Use Cases - Customer 360: one launchpad combining transaction history, inquiries, related orders, and account owners for sales. - Equipment record: a maintenance home screen with sensor values, service history, related parts, and open tickets. - Case management: a single view of stakeholders, due dates, approval status, and next actions on a case object. ⚠️ Caveats - Views depend on the quality of the underlying ontology modeling (object types and link types); a weak foundation limits view quality. - Overloading a view confuses users, so design role-specific layouts that show only what each role needs. - Editing requires appropriate permissions to the Ontology Manager and the underlying Workshop module. #PalantirFoundry# #DataPlatform#

🧠 誤差逆伝播を使わない「生物学的に妥当な学習」が深いネットワークで失敗するのは、実は勾配のランク崩壊が原因でした。それを幾何学的な介入で解き、精度を1.4%から46.1%へ一気に引き上げた研究です。 タイトル: Overcoming Rank Collapse in Feedback Alignment URL: 📝 概要 フィードバックアラインメント（FA）は、誤差逆伝播に対する生物学的に妥当な代替手法です。順方向と同じ重みを逆方向にも使う「対称な重み転送」を必要とせず、固定のランダムなフィードバック重みで学習します。本論文は、FAが深い構造でスケールしない原因を「勾配のランク崩壊」と特定し、それを克服する手法を提案します。 ❓ 解決する課題 FAの誤差は、逆伝播に比べて著しくランクが低く、より低次元の部分空間に制約されてしまいます。このランク崩壊が、パラメータ空間の探索を大きく制限し、学習中に重みの整合（alignment）が進まなくなる根本原因でした。 💡 方法論と提案手法 勾配の次元性を高める、相補的な2つの機構を提案します。 ・Muonオプティマイザ：直交化に基づき、すべての特異値を1に設定します。モメンタム更新のスペクトルを平坦化し、これまで無視されていた方向を強調して、更新の幾何そのものを書き換えます ・バッチ正規化：隠れ層の活性を正規化して活性の直交性を促し、層をまたいで高次元の表現を維持します ・Muonは更新の幾何を均一化し、バッチ正規化は表現の次元性を保つ。両者を組み合わせると、学習を通じて豊かな学習方向が維持され、深いネットワークでもアラインメントが生まれます 🎯 ユースケース 逆伝播に依存しない学習や、脳に着想を得たニューロモルフィック計算、そして「最適化の軌跡の次元性」を扱う研究全般に役立ちます。 📊 実験結果 ・CIFAR-10・CIFAR-100・STL-10・Tiny ImageNetで、AlexNetとResNet-18を用いて評価しました ・CIFAR-100・ResNet-18では、ベースラインFAがわずか1.4%だったのに対し、FA+バッチ正規化で37.1%、FA+Muonで25.3%に向上しました ・FA+Muon+バッチ正規化で46.1%（バッチ正規化単独比で約9ポイント改善）を達成しました ・同様の改善が、すべてのデータセットとアーキテクチャで確認されました #DeepLearning# #Neuroscience#