G2VLM: Geometry Grounded Vision Language Model with Unified 3D Reconstruction and Spatial Reasoning

G2VLM is a geometry-grounded vision-language model designed to address one of the most persistent weaknesses of modern vision-language models (VLMs): spatial understanding and reasoning. While recent VLMs have achieved remarkable success in image understanding, multimodal dialogue, and visual question answering, they often struggle with tasks that require a deeper grasp of three-dimensional structure, object relationships, depth, and spatial reasoning. The authors argue that this limitation arises because most VLMs learn primarily from large collections of two-dimensional images paired with text and therefore lack an explicit mechanism for reconstructing and understanding the geometry of the physical world. 

To overcome this problem, the paper proposes a unified framework that combines 3D visual geometry learning with high-level multimodal reasoning. Rather than treating images as flat visual inputs, G2VLM learns to infer the underlying three-dimensional structure of scenes and then uses this geometric knowledge to support spatial reasoning. According to the authors, spatial intelligence depends on both identifying objects and understanding their locations and physical relationships. G2VLM is designed to model both capabilities simultaneously. 

The architecture is inspired by the neuroscience concept of the two-streams hypothesis, which proposes separate pathways for recognizing objects ("what") and understanding spatial relationships ("where"). Reflecting this idea, G2VLM uses a Mixture-of-Transformer-Experts (MoT) architecture containing two specialized components. The first is a geometric perception expert, responsible for learning 3D geometry, reconstructing point clouds, estimating depth, and predicting camera poses from image inputs. The second is a semantic perception expert, built upon a pretrained vision-language model, which performs multimodal understanding and language reasoning. Rather than operating independently, these experts share attention mechanisms that allow geometric and semantic information to interact and reinforce one another. 

A key contribution of the work is its ability to learn geometry from ordinary images and videos without requiring extensive handcrafted 3D supervision during downstream reasoning tasks. The model is trained in two stages. First, the semantic component is frozen while the geometric expert learns rich 3D representations from large-scale datasets containing geometric annotations such as depth and camera information. Next, the semantic expert is unfrozen and jointly trained with the geometric expert on spatial understanding tasks. This second stage allows the language model to incorporate learned geometric representations into its reasoning process, producing a system that can both reconstruct scenes and answer spatial questions about them. 

The geometric learning process is sophisticated and centers on reconstructing the three-dimensional structure of scenes. The model predicts pixel-aligned 3D point maps and camera poses, using losses that measure point reconstruction accuracy, camera pose estimation quality, and surface normal consistency. Through these objectives, the geometric expert acquires a detailed understanding of spatial layouts, depth relationships, and scene structure. Unlike systems focused solely on geometric reconstruction, however, G2VLM integrates these capabilities directly into a language model, enabling geometry to influence reasoning and decision-making. 

Experimental results demonstrate the effectiveness of this unified approach. On visual geometry benchmarks, G2VLM achieves performance comparable to state-of-the-art reconstruction systems such as VGGT. The model shows strong results on tasks including monocular depth estimation, point reconstruction, and camera pose estimation. For example, the paper reports an improvement in Absolute Relative Error on the Sintel depth benchmark, reducing the error from 0.335 to 0.297 compared with VGGT. 

The model also performs exceptionally well on spatial reasoning tasks. Across multiple benchmarks designed to evaluate understanding of spatial relationships and physical scene structure, G2VLM matches or exceeds the performance of significantly larger models. The paper highlights particularly strong performance on SPAR-Bench, where G2VLM surpasses GPT-4o by 18.5 percentage points. Notably, these results are achieved with a relatively compact 2-billion-parameter model, suggesting that explicit geometric grounding may be more valuable for spatial reasoning than simply scaling model size. 

An important finding from the study is the positive interaction between geometric and semantic learning. As the geometric expert improves its ability to reconstruct 3D scenes, the semantic reasoning capabilities of the model also improve. This supports the authors’ central hypothesis that robust spatial reasoning requires a dedicated understanding of geometry rather than reliance solely on language patterns or two-dimensional visual cues. 

In conclusion, the paper presents G2VLM as the first unified model that simultaneously performs high-quality 3D reconstruction and advanced spatial reasoning within a single vision-language framework. By incorporating an explicit geometric perception pathway and allowing it to interact closely with semantic reasoning, the model bridges a gap between low-level visual geometry and high-level multimodal intelligence. The results suggest that future progress in spatial intelligence, robotics, embodied AI, and potentially applications such as 3D scene editing may benefit significantly from integrating geometric understanding directly into foundation models. 

References: https://arxiv.org/html/2511.21688v1 

 Migration strategy for permanent role-based assignments in Azure for resources in a subscription: 

This article describes a logical end state that becomes possible after an initial review, cleanup and optimization and justifies it to stakeholders who often want to contend that delivery requirements can be met by cleanup and optimization alone. The state is realized through an entitlement model that separates business access decisions from Azure implementation details, which allows the access model to survive platform, application, and organizational change over many years. 

First, we must acknowledge that there are near-term economics in doing just cleanup without imposing any model or organization. Converting existing permanent assignments into eligible PIM assignments, consolidating resource-level role assignments to resource-group scope, and reducing the number of direct RBAC assignments is probably the fastest path to risk reduction. It produces measurable audit benefits quickly, requires relatively little redesign, minimizes disruption to application teams, and largely preserves today's operational model. This is an infrastructure optimization exercise. It makes today's model cleaner without fundamentally changing how access is governed. 

Second, we are solving a problem we typically uncover in the analysis that this is a dual problem of RBAC-assignment and identity-governance. Same combinations of Azure roles repeat across users over and over again but often manifest through many different groups and custom-role variations. While we can reduce those patterns into a relatively small number of reusable job-function personas and highlight where custom roles represent specialized business functions rather than merely technical permissions. The fact that the same role combinations repeatedly emerge is evidence that people naturally organize around business responsibilities such as application development, application operations, platform engineering, storage administration, integration engineering, and data engineering, not around individual Azure resources. The entitlement catalog therefore models the way work is performed rather than the way Azure resources happen to be arranged today. The entitlement model separates "what job a person performs" from "where resources happen to live." In effect, the model transforms access management from a collection of infrastructure-specific permissions into a business-driven authorization framework that can evolve independently of resource groups, subscriptions, applications, and cloud platforms 

Third, resource groups are not stable business constructs. They are deployment constructs. Applications move between subscriptions, environments are restructured, landing zones evolve, new resource types are introduced, acquisitions occur, and cloud architectures change. A resource-group-centric model assumes that the resource-group boundary is the most important long-term boundary. History shows that those boundaries change frequently. Job functions, however, change much more slowly. There will almost certainly still be application developers, platform engineers, storage administrators, and integration engineers five years from now, even if the names of the subscriptions, resource groups, AKS clusters, Key Vaults, Databricks workspaces, Event Hubs namespaces, or storage accounts have changed entirely. Because personas are aligned with enduring business responsibilities, they are inherently more resilient than resource-centric RBAC designs. 

Fourth, custom roles are where the resource-group approach becomes increasingly difficult to maintain. While we can create custom roles that span multiple resource types within a resource group, that. works successfully only when there are a small number of applications and a small number of resource patterns. Eventually, however, they proliferate and differ only slightly from one another. At that point nobody can confidently answer simple questions such as "What does a Data Engineer receive?" or "Why does this application team need this custom role?" The entitlement model addresses this by making roles implementation details and personas the primary unit of governance. A manager approves "Data Engineer" or "Platform Engineer." The underlying RBAC bundle can evolve without repeatedly re-educating reviewers and makes subsequent access reviews more transparent and easier to complete for managers. 

Fifth, the entitlement model scales much better for certification, audit, and compliance activities. Resource-group-based reviews require reviewers to evaluate technical assignments and with full purview of current landscape and historical context: Contributor on resource group A, Key Vault role on resource group B, Event Hubs role on resource group C, and so forth. A persona model allows reviewers to answer a far simpler question: "Does this person still perform the duties of a Platform Engineer?" Most auditors, application owners, and managers can answer that question confidently; far fewer can evaluate dozens of Azure RBAC assignments in context. The result is better access reviews and lower risk of rubber-stamp approvals. 

Sixth, the entitlement model future-proofs hybrid and multi-platform environments. Today's discussion centers on Azure RBAC, but tomorrow there may be a need to govern Azure, Databricks, Snowflake, GitHub, ServiceNow, Kubernetes, SaaS platforms, and on-premises systems together. Resource-group-driven governance does not extend naturally beyond Azure. Personas do. A "Data Engineer" entitlement can someday include Azure roles, Databricks workspace permissions, GitHub repository access, and Snowflake roles. That makes the model extensible in directions that are probably impossible to predict today. 

Seventh, initial reviews often find that users cannot cleanly fit into a reusable entitlement and therefore require exceptions or that users wear multiple hats and can change them. In other words, the model does not merely assign people to personas; it reveals complexity that currently exists but is hidden behind groups and custom roles. That transparency is valuable because exceptions become specific, measurable, and reviewable instead of remaining embedded inside opaque group memberships and custom role definitions. 

Eighth, this model is not an all-or-nothing proposal. Immediate and interim exercise and the entitlement strategy are complementary. First consolidate RBAC to resource-group scope, remove unnecessary direct assignments, and convert elevated permissions to PIM eligibility. Once that cleanup is complete, the entitlement catalog becomes the governance layer above it. In that model, resource groups remain the technical enforcement boundary while personas become the business-access boundary. Engineers implement RBAC. Managers approve personas. Identity governance teams maintain mappings between the two. Each layer serves its appropriate purpose. 

A cleanup approach optimizes the current state, while the entitlement approach creates a durable operating model. One reduces administrative effort today. The other reduces administrative effort every year thereafter. If the organization expects the application portfolio, cloud footprint, custom roles, and hybrid platforms to continue growing, then investing in personas is not a fad. It is the architectural layer that prevents access management from becoming increasingly tied to the accidental structure of today's Azure environment. The reason to adopt personas is that they are the only abstraction in the model that represents stable business responsibilities rather than transient cloud infrastructure. 

 """Self-check for tests/photogrammetry_fixtures.py 

Run: pytest tests/test_photogrammetry_fixtures.py --no-cov

"""

import json

import urllib.request

import cv2

import numpy as np

from core.azure.survey_corners import track_from_srt

from tests.photogrammetry_fixtures import ( # noqa: F401 (fixtures are imported for pytest)

    encode_multipart,

    fake_nodeodm,

    frame_overlap_fraction,

    ground,

    ground_truth_orthomosaic,

    no_gps_tour,

    two_tours,

    union_bbox_px,

)

def _post(url, fields, files=()):

    body, content_type = encode_multipart(fields, list(files))

    request = urllib.request.Request(url, data=body, headers={"Content-Type": content_type}, method="POST")

    return json.load(urllib.request.urlopen(request))

def _get_json(url):

    return json.load(urllib.request.urlopen(url))

def test_tours_have_the_configured_overlap_and_share_area(ground, two_tours):

    a, b = two_tours

    assert len(a.frames) > 10 and len(b.frames) > 10

    # consecutive frames along a flight line overlap ~75 % (the default forward overlap)

    assert abs(frame_overlap_fraction(a.frames[0], a.frames[1]) - 0.75) < 0.05

    # the two tours overlap each other (shared flight lines), so one mosaic can be built from both

    assert any(frame_overlap_fraction(fa, fb) > 0.3 for fa in a.frames for fb in b.frames)

    x0, y0, w, h = union_bbox_px([a, b])

    assert ground_truth_orthomosaic(ground, [a, b]).shape[:2] == (h, w)

def test_tour_writes_frames_srt_and_manifest_that_survey_corners_can_parse(two_tours, no_gps_tour, tmp_path):

    a, _ = two_tours

    paths = a.write(tmp_path / "a")

    assert len(paths) == len(a.frames) and (tmp_path / "a" / "frame1.jpg").exists()

    manifest = json.loads((tmp_path / "a" / "manifest.json").read_text())

    assert [m["frame_id"] for m in manifest] == [f.frame_id for f in a.frames]

    track = track_from_srt(str(tmp_path / "a" / "tourA.SRT")) # the real parser used by /corners

    assert track is not None and len(track) == len(a.frames)

    assert np.ptp(track[:, 0]) > 50 # ~112 m east span

    no_gps_tour.write(tmp_path / "n")

    assert not list((tmp_path / "n").glob("*.SRT")) # no telemetry for the no-GPS tour

    assert all(m["lat"] is None for m in json.loads((tmp_path / "n" / "manifest.json").read_text()))

def test_frame_lat_lon_matches_its_pixel_position(ground, two_tours):

    f = two_tours[0].frames[0]

    gt = ground.geotransform()

    cx, cy = f.bbox_px[0] + f.bbox_px[2] / 2, f.bbox_px[1] + f.bbox_px[3] / 2

    assert abs(f.lat - (gt["origin_lat"] + cy * gt["lat_per_px"])) < 1e-8

    assert abs(f.lon - (gt["origin_lon"] + cx * gt["lon_per_px"])) < 1e-8

def test_fake_nodeodm_task_lifecycle(ground, two_tours, fake_nodeodm):

    a, b = two_tours

    x0, y0, w, h = union_bbox_px([a, b])

    options = json.dumps([{"name": "fast-orthophoto", "value": True}])

    task = _post(fake_nodeodm.url + "/task/new", {"name": "t", "options": options},

                 [("images", fr.filename, b"x") for fr in a.frames[:3]])["uuid"]

    assert fake_nodeodm.tasks[task].images == [fr.filename for fr in a.frames[:3]]

    codes = [_get_json(f"{fake_nodeodm.url}/task/{task}/info")["status"]["code"] for _ in range(4)]

    assert codes == [10, 20, 20, 40] # queued, running, running, completed

    png = urllib.request.urlopen(f"{fake_nodeodm.url}/task/{task}/download/orthophoto.tif").read()

    mosaic = cv2.imdecode(np.frombuffer(png, np.uint8), cv2.IMREAD_COLOR)

    assert mosaic.shape[:2] == (h, w) # the ground-truth orthomosaic

    shots = _get_json(f"{fake_nodeodm.url}/task/{task}/download/shots.geojson")

    assert len(shots["features"]) == len(a.frames) + len(b.frames)

    _post(fake_nodeodm.url + "/task/cancel", {"uuid": task})

    assert _get_json(f"{fake_nodeodm.url}/task/{task}/info")["status"]["code"] == 50 # cancelled

#codingexercise: Codingexercise-10-18-2026.docx

 Migration strategy for permanent role-based assignments in Azure for resources in a subscription:

This article describes a logical end state that becomes possible after an initial review, cleanup and optimization and justifies it to stakeholders who often want to contend that delivery requirements can be met by cleanup and optimization alone. The state is realized through an entitlement model that separates business access decisions from Azure implementation details, which allows the access model to survive platform, application, and organizational change over many years.

First, we must acknowledge that there are near-term economics in doing just cleanup without imposing any model or organization. Converting existing permanent assignments into eligible PIM assignments, consolidating resource-level role assignments to resource-group scope, and reducing the number of direct RBAC assignments is probably the fastest path to risk reduction. It produces measurable audit benefits quickly, requires relatively little redesign, minimizes disruption to application teams, and largely preserves today's operational model. This is an infrastructure optimization exercise. It makes today's model cleaner without fundamentally changing how access is governed.

Second, we are solving a problem we typically uncover in the analysis that this is a dual problem of RBAC-assignment and identity-governance. Same combinations of Azure roles repeat across users over and over again but often manifest through many different groups and custom-role variations. While we can reduce those patterns into a relatively small number of reusable job-function personas and highlight where custom roles represent specialized business functions rather than merely technical permissions. The fact that the same role combinations repeatedly emerge is evidence that people naturally organize around business responsibilities such as application development, application operations, platform engineering, storage administration, integration engineering, and data engineering, not around individual Azure resources. The entitlement catalog therefore models the way work is performed rather than the way Azure resources happen to be arranged today. The entitlement model separates "what job a person performs" from "where resources happen to live." In effect, the model transforms access management from a collection of infrastructure-specific permissions into a business-driven authorization framework that can evolve independently of resource groups, subscriptions, applications, and cloud platforms

Third, resource groups are not stable business constructs. They are deployment constructs. Applications move between subscriptions, environments are restructured, landing zones evolve, new resource types are introduced, acquisitions occur, and cloud architectures change. A resource-group-centric model assumes that the resource-group boundary is the most important long-term boundary. History shows that those boundaries change frequently. Job functions, however, change much more slowly. There will almost certainly still be application developers, platform engineers, storage administrators, and integration engineers five years from now, even if the names of the subscriptions, resource groups, AKS clusters, Key Vaults, Databricks workspaces, Event Hubs namespaces, or storage accounts have changed entirely. Because personas are aligned with enduring business responsibilities, they are inherently more resilient than resource-centric RBAC designs.

Fourth, custom roles are where the resource-group approach becomes increasingly difficult to maintain. While we can create custom roles that span multiple resource types within a resource group, that. works successfully only when there are a small number of applications and a small number of resource patterns. Eventually, however, they proliferate and differ only slightly from one another. At that point nobody can confidently answer simple questions such as "What does a Data Engineer receive?" or "Why does this application team need this custom role?" The entitlement model addresses this by making roles implementation details and personas the primary unit of governance. A manager approves "Data Engineer" or "Platform Engineer." The underlying RBAC bundle can evolve without repeatedly re-educating reviewers and makes subsequent access reviews more transparent and easier to complete for managers.

Fifth, the entitlement model scales much better for certification, audit, and compliance activities. Resource-group-based reviews require reviewers to evaluate technical assignments and with full purview of current landscape and historical context: Contributor on resource group A, Key Vault role on resource group B, Event Hubs role on resource group C, and so forth. A persona model allows reviewers to answer a far simpler question: "Does this person still perform the duties of a Platform Engineer?" Most auditors, application owners, and managers can answer that question confidently; far fewer can evaluate dozens of Azure RBAC assignments in context. The result is better access reviews and lower risk of rubber-stamp approvals.

Sixth, the entitlement model future-proofs hybrid and multi-platform environments. Today's discussion centers on Azure RBAC, but tomorrow there may be a need to govern Azure, Databricks, Snowflake, GitHub, ServiceNow, Kubernetes, SaaS platforms, and on-premises systems together. Resource-group-driven governance does not extend naturally beyond Azure. Personas do. A "Data Engineer" entitlement can someday include Azure roles, Databricks workspace permissions, GitHub repository access, and Snowflake roles. That makes the model extensible in directions that are probably impossible to predict today.

Seventh, initial reviews often find that users cannot cleanly fit into a reusable entitlement and therefore require exceptions or that users wear multiple hats and can change them. In other words, the model does not merely assign people to personas; it reveals complexity that currently exists but is hidden behind groups and custom roles. That transparency is valuable because exceptions become specific, measurable, and reviewable instead of remaining embedded inside opaque group memberships and custom role definitions.

Eighth, this model is not an all-or-nothing proposal. Immediate and interim exercise and the entitlement strategy are complementary. First consolidate RBAC to resource-group scope, remove unnecessary direct assignments, and convert elevated permissions to PIM eligibility. Once that cleanup is complete, the entitlement catalog becomes the governance layer above it. In that model, resource groups remain the technical enforcement boundary while personas become the business-access boundary. Engineers implement RBAC. Managers approve personas. Identity governance teams maintain mappings between the two. Each layer serves its appropriate purpose.

A cleanup approach optimizes the current state, while the entitlement approach creates a durable operating model. One reduces administrative effort today. The other reduces administrative effort every year thereafter. If the organization expects the application portfolio, cloud footprint, custom roles, and hybrid platforms to continue growing, then investing in personas is not a fad. It is the architectural layer that prevents access management from becoming increasingly tied to the accidental structure of today's Azure environment. The reason to adopt personas is that they are the only abstraction in the model that represents stable business responsibilities rather than transient cloud infrastructure.

 Insider-Risk Management with DVSA (https://github.com/ravibeta/dvsa-api) platform: 

Insider risk concerns model behavior and outputs that could significantly affect the analytics stack DVSA provides for drone AI applications, as described in the eponymous article. This document applies that article’s recommended trust architecture to our system. 

Models act like powerful insiders: they have access, intent, and the ability to act. DVSA relies on them for tasks ranging from geospatial pipelines to feedback control loops in critical mission systems. Our earlier work proposed two safeguards. The first is a health signal that measures semantic drift as the cosine distance between rolling embedding centroids. The second is a tiered architecture in which Qdrant global search and LLM agent reasoning run in the cloud. We now extend our scope beyond the data and infrastructure to the models themselves: how they act, which tools they can call, and how they might be manipulated or abused. 

In DVSA, every model, agent, and tool is an insider whose capabilities could leak information, misroute queries, amplify bias, or be steered by hostile input. We test the agent layer against prompt-injection attacks that hide directives in video metadata, and we mitigate them with SQL schema allowlists and input sanitization. We also protect data with AES-256-GCM encryption and differential privacy. Three principles govern every potential insider action: least privilege, strong provenance, and continuous monitoring. 

Least privilege begins with tools. The agentic retrieval layer exposes eight specialized functions, from semantic frame search to heatmap generation, and each should be tightly scoped. An agent answering a parking-lot query, for instance, should search only the relevant account, mission, and time window rather than the entire corpus. In Azure AI Search, we add accountid and video-id as filterable fields and pass OData filters such as odata_filter = "accountid eq '008333'". As a result, queries reach only the vectors derived from the user’s own uploaded videos, even though the index is shared across users. These filters are mandatory. Every agent tool call must carry tenant and mission context, which the API enforces and a policy engine such as Open Policy Agent validates. A model should never see more data than the current question requires. 

Provenance and lineage form the second pillar. We already attach provenance atomically at ingest and maintain full lineage graphs that trace every transformation from raw frame to archived artifact. These graphs support compliance audits, targeted reprocessing after model upgrades, and complete erasure cascades. We can extend this lineage to model decisions. Azure already produces a trace for every agent run, recording the tools called, frames retrieved, filters applied, model versions used, and the content of the final answer. These traces become our insider-activity logs. We can mine them for anomalies, such as an agent suddenly querying beyond its usual geospatial bounds or calling tools in a sequence that resembles reconnaissance rather than analysis. We then feed them into the same observability stack that monitors ingestion, localization, and drift. The result is a new signal, “model behavior drift,” which measures how far today’s tool-calling patterns deviate from a baseline of legitimate use. 

Exfiltration and misuse map cleanly onto DVSA’s multi-tenant, high-value corpus, because aerial urban video is sensitive by default. Our GDPR section already addresses this through four measures: purpose limitation enforced at flight-plan registration, importance sampling for data minimization, cascading deletion across the provenance database, S3, and Qdrant vectors, and latitude-longitude-time frame search for data subject access requests. We can add exfiltration guards at the agent layer. These would detect queries that resemble bulk export, such as “give me all frames with cars in Redmond between 2023 and 2025,” cap result sizes and aggregation granularity, and require elevated approval or out-of-band justification for queries that exceed those caps. We must scan not only prompts and their metadata but also the model behavior that attempts to fulfill them. 

Model supply chain and configuration drift are another dimension. DVSA requires embeddings to carry model-version metadata and orthophotos to be refreshed quarterly, and we trigger re-embedding when measured drift crosses a threshold. Building on this, we can treat model binaries, configuration files, and tool registries as high-risk artifacts. Any change to CLIP, YOLO, Qdrant index parameters, or agent tool definitions should pass through signed, auditable change control. Our dvsa_ Prometheus namespace can expose configuration hashes and model-version distributions and raise an alert when an unexpected version reaches production. This is how we catch a compromised model or misconfigured tool before it behaves like a malicious insider. 

Segmentation and isolation ensure that no single insider sees everything. DVSA’s tiered edge-versus-cloud architecture already provides a degree of segmentation, with Qdrant global search and LLM agent reasoning confined to the cloud. We can strengthen it in two ways: edge agents see only their own mission’s embeddings and metadata, and cloud agents operate in per-tenant namespaces with strict cross-tenant barriers. For cross-mission analytics, we can introduce specialized “auditor” agents with narrower tools and stronger logging instead of letting general-purpose agents roam the corpus. In effect, we assign our models roles, such as mission analyst, fleet auditor, and compliance checker, and give each role its own toolset and data scope. 

Finally, observability should cover activities as well as metrics. Alongside existing metrics such as agent task-completion rate and cost per query, we can add agent intent classification and tool-use entropy. A lightweight classifier could label each agent run as normal analysis, exploratory browsing, or suspicious bulk access based on its tool sequence, filter breadth, and result size. Tracking tool-use entropy per agent would reveal sudden spikes in unusual tools or filters that may indicate insider-like exploration. 

Taken together, these measures meet the expectations for insider-risk management: treating models, agents, and tools as insiders; atomic provenance; semantic drift monitoring; tiered edge and cloud deployment; access control lists; encryption; differential privacy; and a rich observability stack. 

 

Reference:  Insider risk eponymous article: https://snscratchpad.com/posts/models-as-insider-risks/