Imagine your infrastructure pipeline is running perfectly . . . until it isn’t. You apply a routine security patch to a Terraform module, review the plan, and hit approve. Everything looks fine in the logs. But ten minutes later your phone rings. The director of customer support is livid. Customers are flooding her team with calls over orders processing incorrectly. When you investigate, you discover that a two-day-old version of the application was quietly re-deployed, reverting critical business logic changes, without a single alert. You had no idea. But now, you are responsible for cleaning up a customer-facing, revenue-impacting mess. This is the result of version drift, the inevitable consequence of two deployment systems that do not share a source of truth.

The good news is that this version drift is preventable. Part 1 of this series describes the Terraform side of the solution, the SSM Registry Pattern. [Link to Part 1 to be added when published.] Instead of hardcoding application versions in the infrastructure code, the pattern reads them live from AWS Systems Manager Parameter Store at apply time. SMS’s DevOps managed services implemented this pattern working closely with Gridline, a financial technology firm, and it is now running in their production environment. However, Terraform can only read what the application CI writes. This post covers that side of the pattern. It details the GitHub Actions workflow that updates the registry after every successful deployment and the infrastructure pipeline that reads from it before each Terraform apply.

The following diagram shows how the workflows leverage SSM Parameter Store as a version registry:

The Application’s Role

The version registry only works if something writes to it. That responsibility belongs to the application CI.

After every successful deployment, the application workflow writes the deployed version to SSM. For an ECS service, the version is the Git commit SHA used as the image tag. For a Lambda function, it is the S3 object key of the deployment package. The write happens after the artifact is confirmed deployed, not before, not speculatively. If the deployment fails, SSM is not updated. The registry always reflects a version that is known to have deployed successfully.s own pace.

This is the contract between the two systems. The application CI owns the write. The infrastructure code owns the read. Neither system reaches into the other’s territory.pull request.

The ECS Deployment Workflow

The code samples in the following sections come from a companion repository with a full working implementation. Here’s the full deploy-api.yml workflow:

name: Deploy API

on:
  push:
    branches: [main]
    paths: [“apps/api/**”]
  workflow_dispatch:

# In a real setup, apps/api/ would live in its own repository and this
# workflow would be at the root of that repo. It is co-located here for
# the purposes of the blog sample.

permissions: {}

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      IMAGE_TAG: ${{ github.sha }}
    permissions:
      id-token: write # required for OIDC role assumption
      contents: read
    steps:
      – name: Checkout
        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

      – name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@ec61189d14ec14c8efccab744f656cffd0e33f37 # v6.1.0
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      – name: Log in to Amazon ECR
        id: ecr-login
        uses: aws-actions/amazon-ecr-login@19d944daaa35f0fa1d3f7f8af1d3f2e5de25c5b7 # v2.1.4

      – name: Build and push container image
        env:
          ECR_REGISTRY: ${{ steps.ecr-login.outputs.registry }}
        run: |
          if aws ecr describe-images \
            –repository-name “${{ vars.PROJECT_NAME }}-api” \
            –image-ids “imageTag=$IMAGE_TAG” > /dev/null 2>&1; then
            echo “Image $IMAGE_TAG already exists in ECR — skipping build and push”
          else
            docker build \
              –platform linux/amd64 \
              –tag “$ECR_REGISTRY/${{ vars.PROJECT_NAME }}-api:$IMAGE_TAG” \
              ./apps/api
            docker push “$ECR_REGISTRY/${{ vars.PROJECT_NAME }}-api:$IMAGE_TAG”
          fi

      – name: Register new ECS task definition revision
        id: register-task
        env:
          ECR_REGISTRY: ${{ steps.ecr-login.outputs.registry }}
        run: |
          CURRENT=$(aws ecs describe-task-definition \
            –task-definition “${{ vars.PROJECT_NAME }}-api” \
            –query taskDefinition \
            –output json)

          # Select the target container by name so sidecars do not interfere.
          UPDATED=$(echo “$CURRENT” | jq \
            –arg IMAGE “$ECR_REGISTRY/${{ vars.PROJECT_NAME }}-api:$IMAGE_TAG” \
            –arg NAME “api” \
            ‘del(.taskDefinitionArn,.revision,.status,.requiresAttributes,.compatibilities,.registeredAt,.registeredBy)
             | (.containerDefinitions[] | select(.name == $NAME)).image = $IMAGE’)

          TASK_DEF_ARN=$(aws ecs register-task-definition \
            –cli-input-json “$UPDATED” \
            –query taskDefinition.taskDefinitionArn \
            –output text)

          echo “task_def_arn=$TASK_DEF_ARN” >> “$GITHUB_OUTPUT”

      – name: Update ECS service
        run: |
          aws ecs update-service \
            –cluster “${{ vars.PROJECT_NAME }}-cluster” \
            –service “api” \
            –task-definition “${{ steps.register-task.outputs.task_def_arn }}”

          aws ecs wait services-stable \
            –cluster “${{ vars.PROJECT_NAME }}-cluster” \
            –services “api”

      – name: Write version to SSM
        run: |
          aws ssm put-parameter \
            –name “/app/${{ vars.ENVIRONMENT }}/versions/api” \
            –value “$IMAGE_TAG” \
            –type “String” \
            –overwrite

A few things are worth calling out.

Action versions are pinned to SHA hashes. Each uses: line references a 40-character commit SHA rather than a mutable version tag. A version tag like v4 can be moved to point to different code at any time. A SHA is immutable. This is a supply chain security practice. If a tag is compromised after you pin it, your workflow is unaffected. With supply chain attacks against open-source actions becoming increasingly common, this practice meaningfully reduces your exposure.

AWS authentication uses OIDC. The configure-aws-credentials action assumes an IAM role via the GitHub OIDC provider rather than using long-lived access keys stored as secrets. The role is scoped to the specific AWS actions the workflow requires. No AWS credentials are stored in GitHub. The README.md in the companion repository covers this in additional detail.

The SSM write happens last, after the ECS service is confirmed stable. This is the registry contract. SSM reflects a version that has been successfully deployed, not just built or pushed. If the ECS update fails, the workflow stops and SSM is not updated. The previous SSM value, pointing to the last known good deployment, remains in place.

Task definition registration uses jq to swap the image. The workflow fetches the current task definition, strips the read-only fields that would cause the registration to fail, replaces the image on the target container by name, and registers a new revision. Selecting the container by name rather than by index means the logic is safe when sidecars are present.

The Lambda Deployment Workflow

The full deploy-processor.yml workflow:

name: Deploy Processor

on:
  push:
    branches: [main]
    paths: [“apps/processor/**”]
  workflow_dispatch:

# In a real setup, apps/processor/ would live in its own repository and this
# workflow would be at the root of that repo. It is co-located here for
# the purposes of the blog sample.

permissions: {}

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      IMAGE_TAG: ${{ github.sha }}
    permissions:
      id-token: write # required for OIDC role assumption
      contents: read
    steps:
      – name: Checkout
        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

      – name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@ec61189d14ec14c8efccab744f656cffd0e33f37 # v6.1.0
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      – name: Package Lambda function
        working-directory: apps/processor
        run: zip “processor-${IMAGE_TAG}.zip” handler.py

      – name: Upload package to S3
        run: |
          aws s3 cp \
            “apps/processor/processor-${IMAGE_TAG}.zip” \
            “s3://${{ vars.PROJECT_NAME }}-lambda-packages/processor-${IMAGE_TAG}.zip”

      – name: Update Lambda function code
        run: |
          if aws lambda get-function –function-name “${{ vars.PROJECT_NAME }}-processor” > /dev/null 2>&1; then
            aws lambda update-function-code \
              –function-name “${{ vars.PROJECT_NAME }}-processor” \
              –s3-bucket “${{ vars.PROJECT_NAME }}-lambda-packages” \
              –s3-key “processor-${IMAGE_TAG}.zip”

            aws lambda wait function-updated \
              –function-name “${{ vars.PROJECT_NAME }}-processor”
          else
            echo “Lambda function does not exist yet — skipping update. Terraform will deploy it on the next infra-apply.”
          fi

      – name: Write version to SSM
        run: |
          aws ssm put-parameter \
            –name “/app/${{ vars.ENVIRONMENT }}/versions/processor” \
            –value “processor-${IMAGE_TAG}.zip” \
            –type “String” \
            –overwrite

The structure mirrors the ECS workflow. It packages the function, uploads to S3, updates the function, and writes the S3 object key to SSM only after the update is confirmed.

The S3 key written to SSM is the full object key, processor-<sha>.zip, not just the SHA. Terraform’s s3_existing_package block needs the full key, so that is what the registry stores.

The update-function-code step checks whether the Lambda function exists before attempting the update. This handles the bootstrap scenario. On initial setup or after a full teardown, the Lambda function does not exist until Terraform creates it. The S3 upload completes successfully, giving Terraform everything it needs to create the function on its next apply, and SSM is written after the artifact is in place so it reflects only versions that have been confirmed deployed. In normal operation, the function exists and the update runs unconditionally.

This workflow updates $LATEST directly. Teams using Lambda aliases for blue/green or weighted traffic shifting will need to extend the pattern to also track the published version number alongside the S3 key.

Why the Infra Pipeline Refreshes the Registry First

Terraform stores the output of the version registry module in state. The version_map output, a map of service names to deployed versions, is persisted to the state file on each apply.

Between infrastructure applies, the application CI may deploy new versions and update SSM. Terraform’s state still reflects the versions from the last apply. If the infra pipeline runs a full terraform apply without first refreshing the registry module, Terraform computes its plan using the stale values in state. The plan may show a spurious diff on the image tag or Lambda S3 key, or in the case of the Lambda module, it may attempt to reconcile to a version that no longer matches what CI has deployed.

The fix is a targeted apply on the version registry module before the full apply:

terraform apply -target=module.version_registry -auto-approve
terraform apply -auto-approve

The targeted apply reads the current SSM parameters and updates state. The full apply that follows computes its plan from the refreshed values. The deployed versions in SSM match what is actually running, so the plan shows no diff on image tags or S3 keys.

In this sample, the targeted apply is not strictly necessary because the version registry module lives in the same Terraform root as the rest of the infrastructure. A plain terraform apply would read SSM directly and arrive at the same result. The two-step apply sequence is included because it reflects the pattern you would need to follow in a real-world setup where the version registry is deployed as a separate unit. In that case, the registry must be applied first so its outputs are available to the deployments that depend on them. HashiCorp flags -target as appropriate for exactly this kind of scenario where it is necessary to refresh data inputs that downstream resources depend on at plan time.

The Infrastructure Pipeline

The full infra-apply.yml workflow:

name: Apply Infrastructure

on:
  push:
    branches: [main]
    paths: [“infra/**”]
  workflow_dispatch:

# Prevent concurrent applies. cancel-in-progress: false means a second
# triggered run queues rather than cancels, so no two applies ever race
# on the same state file. This removes the need for a DynamoDB lock table.
concurrency:
  group: terraform-apply
  cancel-in-progress: false

permissions: {}

jobs:
  apply:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # required for OIDC role assumption
      contents: read
    steps:
      – name: Checkout
        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

      – name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@ec61189d14ec14c8efccab744f656cffd0e33f37 # v6.1.0
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      – name: Setup Terraform
        uses: hashicorp/setup-terraform@5e8dbf3c6d9deaf4193ca7a8fb23f2ac83bb6c85 # v4.0.0
        with:
          terraform_version: “1.5.7”

      – name: Terraform init
        working-directory: infra
        run: |
          terraform init \
            -backend-config=”bucket=${{ vars.TF_STATE_BUCKET }}” \
            -backend-config=”key=terraform.tfstate” \
            -backend-config=”region=${{ vars.AWS_REGION }}”

      # Apply the version registry first. This refreshes Terraform’s view of
      # the SSM parameters so that the current deployed versions — written by
      # application CI — are in state before anything else is planned or applied.
      # Without this step, Terraform’s state can lag behind the live SSM values
      # and produce a spurious diff on the image tag or Lambda S3 key.
      – name: Refresh version registry
        working-directory: infra
        run: terraform apply -target=module.version_registry -auto-approve

      – name: Apply all infrastructure
        working-directory: infra
        run: terraform apply -auto-approve

Two design decisions are worth explaining.

The S3 backend uses partial configuration. The main.tf file contains only backend “s3” {} with no bucket name or region. Those values are passed as -backend-config flags at terraform init time, read from GitHub Actions variables. This keeps environment-specific values out of source control and makes the sample portable. Anyone can clone it, set their own TF_STATE_BUCKET variable, and run it without modifying any Terraform files. In production, this pattern also makes it straightforward to use different state buckets per environment without branching the Terraform code. key.

Concurrent applies are prevented with a concurrency group. The cancel-in-progress: false setting means a second workflow run triggered while one is already running will queue rather than cancel. No two applies ever race on the same state file. This sample does not use a DynamoDB lock table. Terraform 1.5.x requires DynamoDB for S3 backend locking, and Terraform 1.10+ adds native S3 locking without DynamoDB. For a single-environment sample, the GitHub Actions concurrency group provides equivalent safety without the additional infrastructure. Production setups running Terraform 1.5.x should add a DynamoDB table.ied is increasingly out of date.

Why Not ignore_changes?

A reader familiar with Terraform will reach for ignore_changes as a solution to version drift. Two variants come up in practice, and both are worth addressing.

The first is ignore_changes = [task_definition] on the ECS service resource. This prevents Terraform from reverting the service to an older task definition revision after the application CI has deployed a newer one. The version drift problem appears to go away. However, the stale version is still hardcoded in the Terraform file. Remove ignore_changes and the drift comes back on the next apply. It is not a fix. It is Terraform looking away.

The second is ignore_changes = [container_definitions] on the task definition resource itself. This prevents Terraform from registering new revisions when the image changes, which stops the rollback. However, it also stops any legitimate image update through Terraform. If you need to change the container image for any reason, such as updating a base image, patching a vulnerability, or onboarding a new service, Terraform cannot help you. The task definition’s most important attribute is now effectively unmanaged. You have not solved the problem. You have hidden it.

There is a deeper problem with both variants. Lifecycle blocks in Terraform cannot reference variables or expressions and must be statically defined. This means a module author cannot expose ignore_changes as behavior that consumers opt into.

In practice, production infrastructure code uses community-vetted modules rather than raw resources. Writing your own Terraform modules from scratch is rarely the right call when the ecosystem already provides well-tested options. This sample uses raw resources for the ECS task definition and service to keep the code readable, but the Lambda function is managed through a public module. That is precisely the point. You cannot add a lifecycle block to a resource inside that module. The workaround that appeared to work for the raw ECS resources is not available at all for Lambda without forking the module or dropping down to raw resources yourself. It is not a pattern that scales.

The SSM registry solves the actual problem. It replaces the stale hardcoded version with a live lookup, so Terraform’s plan reflects what is actually running. There is nothing to suppress.

This division is deliberate. Terraform remains the source of truth for every other aspect of the task definition, including CPU, memory, environment variables, and the task role. The SSM registry handles the one attribute that the application CI owns, the image. Without ignore_changes, infrastructure applies that touch the task definition will trigger an ECS rolling update. Because the image comes from SSM and reflects what is actually running, ECS replaces old containers with new ones running the same image, waits for them to be healthy, and drains the old ones. This is what ECS is designed to do.

What the Plan Looks Like

On first apply after a fresh deployment, the plan output for the Lambda function will show a change on the S3 key:

# module.processor.aws_lambda_function.this[0] will be updated in-place
~ resource “aws_lambda_function” “this” {
    ~ s3_key = “processor-abc1234def5.zip” -> “processor-def5678abc1.zip”
  }

This is the pattern working correctly. The version registry refresh read the current key from SSM, written by deploy-processor, and updated state. The full apply reconciles the Lambda function to match. On subsequent applies where no deployment has occurred, this diff does not appear.with a live lookup.

The ECS task definition shows a similar reconciliation on first apply:

# aws_ecs_task_definition.api must be replaced
-/+ resource “aws_ecs_task_definition” “api” {
    ~ container_definitions = “[{\”image\”:\”…api:abc1234\”,…}]” -> (known after apply) # forces replacement
    ~ revision              = 7 -> (known after apply)
  }

Terraform registers a new task definition revision with the SHA from SSM and updates the ECS service to point to it. As described in the previous section, ECS performs a rolling update. New containers running the same image are health-checked and the old ones are drained. After this first reconciliation, subsequent applies where the SHA has not changed produce no diff.

Rollback

Two options are available when a bad deployment needs to be undone.

The faster option is to re-run the deployment workflow against a known-good commit SHA. Pass the target SHA as a workflow input or manually trigger the workflow from a specific commit. The workflow builds the old image, pushes it, writes the SHA to SSM, and updates ECS or Lambda. Terraform is not involved.

The alternative for ECS is to repoint the service directly to an earlier task definition revision using the AWS CLI:

aws ecs update-service \
  –cluster <cluster-name> \
  –service <service-name> \
  –task-definition <family>:<revision>

aws ecs wait services-stable \
  –cluster <cluster-name> \
  –services <service-name>n.

This gets the service running the old code immediately. Follow it with a re-run of the deployment workflow against the known-good SHA to update SSM and restore consistency. If SSM is left pointing to the bad SHA, the next infrastructure apply will reconcile toward it.

Operational Notes

SSM Parameter Store retains the history of every value written to a parameter. The AWS console shows version history with timestamps under the parameter’s history tab, though it may not display the value for each historical version. The full sequence of deployed SHAs, including values, is reliably available via aws ssm get-parameter-history. Either way, you get a timestamped record of every deployment without any additional tooling.at need a version reference.

SSM Standard parameters are free. There is no charge for storing parameters, reading them with GetParametersByPath, or writing to them with PutParameter. The version registry adds no cost to running this pattern.

There is a narrow timing window between the version registry refresh and the full apply during which a deploy workflow could complete and write a newer version to SSM. If that happens, the full apply uses the version the refresh captured. The next infrastructure apply will reconcile forward correctly. In practice this window is seconds wide, but it is worth knowing about if the infra pipeline and a deploy workflow are triggered simultaneously.

The SSM write is the last step in each deploy workflow and is not retried on transient failure. If it fails after a successful deployment, the running service is at the new version but SSM still reflects the old one. The next infrastructure apply will reconcile toward the stale SSM value. Monitoring the SSM write step and alerting on failure closes this gap.

Adding a service to the registry requires two steps. The application CI workflow writes its version to an SSM parameter under the shared path prefix, and the infrastructure code adds a lookup on module.version_registry.version_map for the new service name. The registry module reads all parameters under the prefix in a single API call. A new service appears in the map automatically on the next apply after its first deployment writes to SSM. There is no list of service names to maintain in the Terraform code.

At Scale

The sample repository consolidates what would normally be three separate repositories (infrastructure, API application, and processor) into a single repo for clarity. In production, each application repository carries its own deployment workflow. The infrastructure repository is separate. The SSM path prefix provides the coordination point between them.

Gridline‘s production implementation runs this pattern across multiple application repositories and AWS environments. The SSM Registry Pattern eliminated the risk of an incident caused by an infrastructure apply overwriting a live deployment. The core module is identical to what is described in this series. The operational scaffolding around it, including environment promotion, pipeline sequencing, and state management, is handled by the surrounding CI infrastructure.

The full working sample, verified against a live AWS environment, is at github.com/sms-data-products/blog-terraform-ssm-version-registry.

The Full Pattern

The two posts in this series trace the SSM Registry Pattern from both sides of the deployment boundary.

Part 1 replaced hardcoded application versions in Terraform with live lookups from SSM, eliminating version drift as a source of silent rollbacks. Part 2 wired up the application workflows that keep SSM current and the infrastructure pipeline that reads from it before applying.

With both in place, application deployments and infrastructure changes run on independent schedules; however, they stay in sync. A module version bump generates a plan that shows only what the bump changes. Application versions are not in the diff.

The natural extensions from here are environment promotion, deliberately writing a validated version to a staging or production SSM path, and adding new services, each of which requires only a deployment workflow that writes to SSM and a lookup in the infrastructure code.

The full working sample, verified against a live AWS environment, is at github.com/sms-data-products/blog-terraform-ssm-version-registry.

Disclaimer: The code samples and architecture described in this post are drawn from a public sample repository at github.com/sms-data-products/blog-terraform-ssm-version-registry, built to illustrate the pattern. They do not represent Gridline‘s actual production configuration.

About Gridline

Gridline is a turnkey private markets platform built to set a new standard for how RIAs operate, manage, and scale alternatives.

We partner with RIAs to make private markets operate as simply as public markets.

Our portfolio management capability gives advisors real-time visibility across every client and every investment, so you’re not waiting on quarter-end reports to understand exposures, performance, or cash flow dynamics. You can drill down by client, fund, or strategy to see the full picture, strengthen transparency, and make faster, better-informed decisions with confidence.

Because the data is always current, meeting prep shrinks and client conversations elevate. Reports are ready when you are. They are clear, accurate, and easy to share, turning portfolio complexity into insight clients can trust.

Where most solutions layer tools on top of fragmented workflows, Gridline is built as core infrastructure: one system that runs the full private markets lifecycle. Gridline centralizes every commitment, capital call, valuation, distribution, and document into a single, always-on source of truth, replacing spreadsheets, portals, and PDFs with an always-on, always-up-to-date source of truth that’s available the moment you need it.

The result is a competitive edge that helps you scale, differentiate your firm, and deliver a modern client experience. 

This is what it means to set a new standard for alternative investing.

Book a call to see how Gridline helps you scale alternatives without scaling complexity.

About the Authors

Imagine this scenario. An infrastructure engineer upgrades the ECS cluster Terraform module from version 5.11.4 to 5.12.0. Routine change. They run terraform apply, review the plan, approve it. Thirty seconds later, the API service is running code from three weeks ago.

No alert fired. No obvious error. A deployment that shipped this morning, validated in staging, approved by the team, carrying a critical fix, has been quietly undone.

This is version drift. It is silent until it causes an incident, and it is a real risk for any team that manages application deployments separately from infrastructure. The good news is that it is entirely preventable.

This post explains why it occurs and introduces the SSM Registry Pattern, the solution that SMS’s DevOps managed services implemented for Gridline, which is now running in their production environment.

How Teams End Up Here

The split between application repositories and infrastructure repositories is a natural consequence of scale.

When you have one service and one team, keeping everything in one place is manageable. When you have a dozen services, each deployed independently by its own team, and a separate infrastructure practice managing the underlying platform, the split is the right call. Application code and infrastructure code change on different schedules, have different reviewers, and carry different risks. Separating them gives each team the autonomy to move at its own pace.

In this model, application deployments bypass Terraform entirely. When an application team pushes a new container image, their CI pipeline builds it, tags it with the commit SHA, pushes it to ECR, and updates the ECS service directly. For a Lambda function, the pipeline zips the package, uploads it to S3, and updates the function. Terraform is not involved. That is by design. Routine application deployments should not require an infrastructure pull request.

However, the infrastructure repository still references those application versions. The ECS task definition must point to a container image. The Lambda function configuration must reference a deployment package. Before the split, both lived in the same codebase and were updated together. After the split, the infrastructure code holds a reference to a version it no longer controls.

Gridline, a financial technology firm running multiple application repositories alongside a mature infrastructure as code setup built on Terraform, recognized that version drift was creating friction as their infrastructure grew. Their team was doing everything right. They had separate repos for application code and infrastructure, CI/CD for both, and versioned Terraform modules pinned across all environments. But the risk of a silent rollback introduced hesitation into every infrastructure change. Engineers had to manually verify deployed versions before applying, slowing down what should have been routine updates. The version drift problem was not a discipline failure. It was an inevitable consequence of two deployment systems that did not share a source of truth. Solving it gave their teams the freedom to deploy infrastructure updates with confidence that application versions would never be silently overwritten.onger controls.

Two Deployment Clocks

Application deployments and infrastructure changes run on fundamentally different schedules.

Application teams deploy frequently. Multiple times per day is common in healthy engineering organizations. Each deployment pushes a new version to the running service without touching the infrastructure code.

Infrastructure changes are less frequent by comparison. A module version upgrade, a security group update, a new IAM policy, a configuration change. When they happen, an engineer runs terraform plan, reviews the output, and applies.

The drift happens at the intersection of these two timelines. Between any two infrastructure applies, the application team has deployed any number of new versions. As soon as the running application version is updated, the Terraform code is out of date because it still references the version that was current the last time anyone ran terraform apply. The next infrastructure change, which may come days or weeks later due to a Terraform module update that addresses a security concern or supports a new configuration option, triggers a plan that includes resetting the service to the old version.

Gridline faced this risk directly after migrating their ECS services and Lambda functions to independent application repositories. With application deployments now running independently of Terraform, any infrastructure change carried the potential for a silent rollback. That meant Gridline faced additional risk any time an infrastructure update was performed.

What Terraform Actually Does

Understanding why this happens requires a clear picture of how Terraform computes a plan.

When Terraform plans an ECS update, it refreshes its state by querying AWS, then compares the refreshed state against the desired state in your .tf files. When there is a hardcoded image tag but the application CI has deployed a newer version, the live ECS service points to a task definition revision that Terraform does not manage. Terraform plans to revert the service to the revision in its state, which still carries the stale image tag. If something else in the task definition has also changed (environment variables, CPU or memory, or the task role), Terraform may register a new revision in the process, but it will carry the stale tag either way. The running container is rolled back to an older version.

The same applies to Lambda functions. When Terraform plans a Lambda update, the application CI has already uploaded a new package to S3 and updated the function. Terraform refreshes and reads the current S3 key from AWS. That value differs from the hardcoded key in the Terraform code. Terraform plans to update the function back to the stale key.

This is not a bug in Terraform. It is a consequence of using Terraform to manage resources that another system is also updating. The state file accurately reflects what Terraform last applied. The problem is that what Terraform last applied is increasingly out of date.

Before: Two Sources of Truth

The core problem is that the image tags are hardcoded in infrastructure code. Subsequent application deployments make them stale. Any infrastructure apply carries the risk of silently rolling back application deployments to an outdated version.

The problem looks like this:

After: One Source of Truth

The fix is to make Terraform read the live deployed version instead of storing a hardcoded one.

AWS Systems Manager Parameter Store serves as the bridge. The application CI writes the deployed version to an SSM parameter immediately after each successful deployment. The version is the container image SHA for ECS services or the S3 object key for Lambda packages. The infrastructure code reads those parameters at apply time using a small Terraform module called the version registry. The hardcoded version is replaced with a live lookup.

The SSM Registry Pattern treats Parameter Store as the single source of truth for deployed application versions, making Terraform a consumer of that truth rather than a holder of a stale copy.ne they need to pause.

When an infrastructure engineer bumps a module version and runs terraform apply, the version registry module reads the current SHA from SSM. The plan reflects the live deployed state. The modifications that are part of the module upgrade show up as changes, but the image tag does not. pause.

The solution looks like this:

The Version Registry Module

The code samples in the following sections come from a companion repository with a full working implementation. The version registry module is small by design. Its only job is to read all SSM parameters under a given path prefix and return them as a map via a Terraform output:

# infra/modules/version-registry/main.tf

variable “ssm_path” {
  description = “SSM path prefix to read versions from, e.g. /app/dev/versions/”
  type        = string
}

data “aws_ssm_parameters_by_path” “versions” {
  path = var.ssm_path
}

output “version_map” {
  description = “Map of service name to deployed version”
  value = {
    for i in range(length(data.aws_ssm_parameters_by_path.versions.names)) :
    basename(data.aws_ssm_parameters_by_path.versions.names[i]) =>
    data.aws_ssm_parameters_by_path.versions.values[i]
  }
}

aws_ssm_parameters_by_path reads every parameter under the given prefix in a single API call. The data source is non-recursive, so service names must live directly under the path prefix. If you nest them, set recursive = true or they will be silently excluded.

The for expression maps each parameter’s trailing path segment, the service name, to its value. A new service appears in the map automatically when it writes its first version to SSM. There is no list of service names to maintain.

Wiring the Module Into the Infrastructure

The companion repository uses a single Terraform root at infra/main.tf for all infrastructure. The version registry module call goes at the top, before any resources that need a version reference.

module “version_registry” {
  source   = “./modules/version-registry”
  ssm_path = “/app/${var.environment}/versions/”
}

locals {
  api_version = lookup(module.version_registry.version_map, “api”, “SEED_REQUIRED”)
  processor_version = lookup(module.version_registry.version_map, “processor”, “SEED_REQUIRED”)
}

The lookup function provides a fallback for the initial setup, before the application CI has written anything to SSM. The SEED_REQUIRED sentinel makes the unsatisfied state obvious. Resources that depend on these locals will fail at apply time with an AWS error pointing at the missing version. The companion repo’s README walks through the full bootstrap sequence, including pushing an initial image to ECR, writing the first SSM parameters, and running the first apply.

The ECS task definition replaces its hardcoded image tag with the local:

resource “aws_ecs_task_definition” “api” {
  # …
  container_definitions = jsonencode([{
    name  = “api”
    image = “${aws_ecr_repository.api.repository_url}:${local.api_version}”
    # …
  }])
}

The Lambda module uses the same pattern for its S3 deployment package key:

module “processor” {
  source  = “terraform-aws-modules/lambda/aws”
  version = “7.4.0”
  # …
  s3_existing_package = {
    bucket = module.lambda_packages_bucket.s3_bucket_id
    key    = local.processor_version
  }
}

In both cases, the version comes from SSM at apply time. If the application CI deployed api:def456 ten minutes ago and wrote that SHA to SSM, the next terraform apply will compute the task definition with api:def456 and leave the latest deployed version untouched.

Pinned Module Versions and Why They Matter Here

The sample repository pins the ECS cluster module and the Lambda module to specific versions from the Terraform Registry rather than using raw aws_ecs_* resources, specifically to preserve the module-upgrade scenario as a realistic trigger for version drift.

module “ecs_cluster” {
  source  = “terraform-aws-modules/ecs/aws”
  version = “5.11.4”
  # …
}

module “processor” {
  source  = “terraform-aws-modules/lambda/aws”
  version = “7.4.0”
  # …
}

This is not incidental. In a production infrastructure repository, module versions are upgraded on a deliberate schedule to pick up security fixes, new features, or provider compatibility updates. Those upgrades are a routine trigger for terraform apply. Without the SSM registry in place, they also carry the risk of silently resetting application versions.

With the registry, a module version bump generates a plan showing only the module changes. The application versions are read live from SSM, match what is running, and produce no diff. That is the before and after in practice.

Extending to Multiple Environments

This sample uses a single environment. In production, the pattern extends cleanly across as many AWS accounts or environments as you need by scoping the SSM path per environment.

Promoting a version from dev to staging is a deliberate act. You write the validated SHA to the staging SSM path and let the staging infrastructure pipeline pick it up on its next apply. It is not an automatic consequence of a push. That deliberate gate is the right model for environment promotion, and the SSM path scoping enforces it naturally.

What’s Next

Part 1 covered the infrastructure side of the pattern. The version registry module reads deployed versions from SSM at apply time. Infrastructure resources reference those live values instead of hardcoded versions. Module upgrades, configuration changes, and routine infrastructure applies can no longer reset a running application to an old version.

Part 2 covers the other side. It walks through the GitHub Actions workflows that write to SSM on every application deployment, how the infrastructure pipeline pre-refreshes the version registry before running, and the operational details that matter in practice. That includes state management, what the plan output looks like on first apply, and how rollback works when you need it.

Disclaimer: The code samples and architecture described in this post are drawn from a public sample repository at github.com/sms-data-products/blog-terraform-ssm-version-registry, built to illustrate the pattern. They do not represent Gridline‘s actual production configuration.

About Gridline

Gridline is a turnkey private markets platform built to set a new standard for how RIAs operate, manage, and scale alternatives.

We partner with RIAs to make private markets operate as simply as public markets.

Our portfolio management capability gives advisors real-time visibility across every client and every investment, so you’re not waiting on quarter-end reports to understand exposures, performance, or cash flow dynamics. You can drill down by client, fund, or strategy to see the full picture, strengthen transparency, and make faster, better-informed decisions with confidence.

Because the data is always current, meeting prep shrinks and client conversations elevate. Reports are ready when you are. They are clear, accurate, and easy to share, turning portfolio complexity into insight clients can trust.

Where most solutions layer tools on top of fragmented workflows, Gridline is built as core infrastructure: one system that runs the full private markets lifecycle. Gridline centralizes every commitment, capital call, valuation, distribution, and document into a single, always-on source of truth, replacing spreadsheets, portals, and PDFs with an always-on, always-up-to-date source of truth that’s available the moment you need it.

The result is a competitive edge that helps you scale, differentiate your firm, and deliver a modern client experience. 

This is what it means to set a new standard for alternative investing.

Book a call to see how Gridline helps you scale alternatives without scaling complexity.

About the Authors

Private markets are not a hedge against reality. They are still exposed to economic cycles, credit conditions, and manager execution. But they behave differently from public markets in ways that matter when volatility shows up.

They are long-duration by design. Most are structured around ten-year terms. They do not reprice continuously on a screen, and they are not built to react to every market movement in real time. That alone changes the rhythm of how risk shows up in a portfolio and the emotional cadence of the client experience.

Not because the underlying assets are immune to pressure, but because the signal clients see is slower, more deliberate, and less reactive. The absence of constant repricing does not remove risk, but it does change how that risk is experienced.

In periods of public market drawdowns, that difference becomes meaningful. Private allocations can provide a steadier center of gravity inside the portfolio. They give advisors more space to anchor conversations in long-term strategy rather than short-term noise, and they reduce the feeling that every headline requires immediate action.

That steadiness is behavioral. When clients are not watching values swing daily, they are more likely to stay aligned with the plan that was built for them, and advisors are better positioned to guide decisions rather than manage reactions.

In fact, in the 2025 Trends in Investing Survey, 69% of financial planners said economic uncertainty and 63% said market volatility were driving them to enhance portfolio resilience through diversification and incorporating alternatives, underscoring how volatility in any asset class leads advisors to broaden their approach.

This is where private markets often earn their place, not by avoiding volatility, but by changing how it shows up and how it is navigated.

Diversification Adds Resilience to Private Portfolios

Advisors know the risk is there. What changes is how that risk surfaces, through cash flows, credit performance, and strategy rotation rather than daily price swings.

Private markets are simply slower-moving on the surface and more complex underneath.

Different strategies move in different environments. Rate drops hurt credit when equity is rallying. Real estate can recover when venture fails to produce exits. Cash flow timing can matter as much as marks.

This is where diversification stops being a slogan and becomes an operating requirement.

Not just diversification across managers, but across strategies, vintages, and liquidity profiles. If you’ve built a diverse portfolio for your clients, if one asset class is underperforming, you’ve got a natural padding in place because the other asset classes may be performing well. You’ve essentially built a portfolio that behaves well across environments.

Volatility Turns Portfolio Questions Into Data Questions

When a client asks, “What is my exposure right now?” they are not asking for a dissertation. They are asking whether you are in control of the moving parts.

That confidence comes from being able to answer questions like:

• What do I own in private markets today, and how much is actually invested versus still unfunded?
• How has this allocation evolved over time, including capital calls and distributions?
• How do we access new valuations with minimal lag as public markets move?
• Where are the concentrations by manager, strategy, and vintage?
• What cash flow obligations could come next, and what is the runway to meet them?

Answering those questions without a scramble changes the tone of the conversation. It keeps advisors present. It keeps clients grounded.

This is Where Infrastructure Quietly Does its Work

An always-on platform does not replace judgment. It supports it by doing three foundational things well.

1. It centralizes private market data that otherwise lives across portals, PDFs, and spreadsheets.
2. It standardizes and structures that information so that different strategies and vehicles can be understood together.
3. And it makes the data easy to retrieve, not just at quarter-end, but whenever questions arise.

The result is not just operational efficiency. It shows up in real ways across the business. Advisors prepare less and engage more. Client conversations feel steadier during volatile moments. Confidence compounds. And over time, that clarity supports growth and retention because clients feel informed, not managed after the fact.

Volatility will always exist. In public markets, in private markets, and across cycles. Diversification helps smooth how that volatility is experienced, but data is what makes diversification explainable and defensible in real time.

When advisors can see the full private portfolio clearly, volatility becomes a conversation they can stay in, not one they need to pause.

About Gridline

Gridline is a turnkey private markets platform built to set a new standard for how RIAs operate, manage, and scale alternatives.

We partner with RIAs to make private markets operate as simply as public markets.

Our portfolio management capability gives advisors real-time visibility across every client and every investment, so you’re not waiting on quarter-end reports to understand exposures, performance, or cash flow dynamics. You can drill down by client, fund, or strategy to see the full picture, strengthen transparency, and make faster, better-informed decisions with confidence.

Because the data is always current, meeting prep shrinks and client conversations elevate. Reports are ready when you are. They are clear, accurate, and easy to share, turning portfolio complexity into insight clients can trust.

Where most solutions layer tools on top of fragmented workflows, Gridline is built as core infrastructure: one system that runs the full private markets lifecycle. Gridline centralizes every commitment, capital call, valuation, distribution, and document into a single, always-on source of truth, replacing spreadsheets, portals, and PDFs with an always-on, always-up-to-date source of truth that’s available the moment you need it.

The result is a competitive edge that helps you scale, differentiate your firm, and deliver a modern client experience. 

This is what it means to set a new standard for alternative investing.

Book a call to see how Gridline helps you scale alternatives without scaling complexity.

About the Author

Private markets have become a much bigger part of the wealth management conversation in recent years. More advisors are spending time on alternatives, more structures are being introduced, and clients are asking more questions about how private investments fit into long-term portfolios. According to Hamilton Lane’s January 2025 report, nearly 60% of financial advisors plan to allocate at least 10% of portfolios to private market investments in the coming year, and nearly a third plan to allocate 20% or more.

At the same time, private investing still comes with real complexity. The timelines are longer, the operational demands are heavier, and the work behind the scenes matters just as much as the opportunity itself.

Joe Polakoff has spent more than two decades in wealth management, navigating that reality from inside advisory firms. Today, he is President of Keebeck Wealth Management, a Chicago-based registered investment advisory (RIA) firm and multifamily office managing just under $2 billion in assets for high-net-worth and ultra-high-net-worth families, many of them private business owners and entrepreneurs.

Polakoff began his career at large institutions including Merrill Lynch before helping build Keebeck with a simple goal: to show up every day as a steady point of contact for clients and a responsible steward of their wealth.

In a recent conversation, he shared a few reflections on what private markets require as more advisory firms expand their exposure. What follows are insights from Polakoff’s experience building private investing into an advisory practice, and the considerations he believes matter as more firms expand into alternatives.

Private Markets Aren’t A Trend Allocation

One of Polakoff’s clearest themes is that alternatives work best when they are approached with real purpose, not because they have become popular or widely discussed.

Private markets come with structural tradeoffs. Illiquidity is real. Holding periods are long. The burden of understanding is higher than in many public market vehicles.

“Just because everybody else is doing it doesn’t mean you should,” Polakoff said. “It really comes down to the individual investor.”

He emphasized the importance of taking the time to understand exactly what is being invested in, and remaining disciplined once commitments are made. Private markets “come with illiquidity,” he noted, and require advisors and clients to be clear about how those investments fit into the broader portfolio.

For Keebeck, the question is always whether an investment fits the client’s goals, liquidity needs, and long-term plan. It also depends on whether the client has a clear understanding of what they own and what they are committing to.

“It’s not a follow-the-herd kind of thing,” he added.

The Advantage Comes From Judgment

Polakoff reflected on how the advisory industry has changed in recent years. In his view, information is no longer scarce. Research, commentary, and market data are widely available, and most advisors have access to the same inputs.

“Data is readily available,” he said. “The skill set is… how can you weed through and identify what is relevant data and then implement on that data?”

For Polakoff, the differentiator is not who can gather the most information, but who can make sound decisions with it. That matters even more in areas like private markets, where investments move on a slower cadence, and clarity often takes more work over time.

He described it as an individual skill: the ability to act thoughtfully and consistently amid constant noise.

“It’s the individual skill set that can actually act on the information,” he said. “That’s where the cream rises to the crop.”

Performance Is More Than Return

Polakoff also framed performance in broader terms than investment outcomes alone.

For him, performance can also mean service, accessibility, and the ability to help clients navigate complexity beyond the portfolio.

“Performance doesn’t always mean a return,” he said. “It can be delivered through a service model… through accessibility… through client coverage.”

He described part of that as “delivering alpha through a service model,” where the advisor becomes the first call not only for investments, but for coordination across estate planning, tax strategy, lending needs, and other moving pieces in a client’s financial life.

In that sense, the advisor’s role is not only portfolio construction. It is stewardship. Helping clients understand their capital, align it with their goals, and stay grounded in long-term decision-making.

Private markets often amplify that responsibility. The investments are more complex, the timelines are extended, and communication becomes more important.

The firms that do this well are not only providing access. They are building clarity and trust around what clients own.

A Practitioner’s Perspective As Private Markets Grow

Private markets are no longer peripheral for many advisory firms. They are becoming a more regular part of portfolio conversations, particularly for high-net-worth families.

Polakoff’s reflections are a reminder that the work is not simply about gaining exposure. It is about approaching private investing with discipline, operational rigor, and a clear understanding of what it requires over time.

In many ways, Polakoff’s perspective aligns with how Gridline thinks about what it means to set a new standard in private market investing: not simply expanding access, but delivering clarity, discipline, and stewardship over time.

For Polakoff, private investing works best when it is tied back to clear goals, implemented with care, and treated as a long-term commitment rather than a headline-driven allocation.

To learn more about how Keebeck Wealth Management is approaching private markets and how they’ve partnered with Gridline, read their story.

About the Author

---

Keebeck Wealth Management is a client of Gridline. The representative of Keebeck has a financial interest in Gridline. Keebeck was not compensated for participating in this case study. The results described reflect Keebeck’s specific experience and are not guaranteed or indicative of future results.

The Challenge with Direct Alternatives Investing

On an investment podcast, the host noted a shift from the traditional 60/40 portfolio to a 50/30/20 allocation that includes alternatives. Given this shift, how should RIAs build and implement an alternatives allocation strategy across their entire client base?

Assume that the alternative investments are private closed-end limited partnerships. One approach is to recommend alternative managers and have clients invest directly. However, this solution is less than ideal for a number of reasons.  For example, some clients end up over-allocated to venture capital because they liked a particular fund pitch. Others might end up with excessive vintage year concentration. And many client portfolios will lack sufficient diversification. While a $100-200 million portfolio targeting 12% in alternatives can achieve sufficient diversification, a $10 million portfolio has only $1.2 million to deploy. With $5-10 million stated fund minimums, this client can access perhaps 1-2 funds, creating massive concentration risk.

Risk management becomes inconsistent for the RIA managing individual alternative allocations for an entire roster of clients. And the administrative burden of private markets is notorious. As assets scale, managing individual client allocations across dozens of funds with inconsistent access, pricing, and service becomes untenable. The operational complexity, regulatory risk, and economic inefficiency will eventually reduce the RIA’s margins in an already competitive low-fee environment. In a crowded Wealth Management marketplace, how can the RIA establish a powerful differentiator with alternatives?

The solution: create a custom fund-of-funds managed by the RIA.    

Benefits of a Custom Fund-of-Funds for RIAs and Clients

With pooled capital, the custom fund-of-funds (custom fund) can hold positions in best-in-class managers across the spectrum of private closed-end funds. RIAs can build precise allocations: 40% private equity, 20% venture capital, 30% private credit, and 10% real assets. The RIA can methodically build positions across multiple vintage years (e.g., 2026, 2027, 2028, 2029). This approach smooths return patterns and reduces timing risk. Over time, the custom fund builds an audited track record. This track record becomes a powerful marketing asset with demonstrable, verifiable alpha.

From Portfolio Construction to Client Impact

With a custom fund approach, every client receives institutional-quality, professionally diversified exposure. This holds whether they invest $500,000 or $10 million. This democratization of access is a powerful value proposition that can increase client stickiness and facilitate new client acquisition. Clients can trust that the RIA’s economic interests are fully aligned with generating the best possible risk-adjusted returns. They don’t have to worry about being placed in accessible funds instead of optimal ones.

And while illiquidity is often presented as a drawback, it creates powerful retention. Clients with 12-15% of their portfolio in the fund-of-funds cannot easily move to another advisor without triggering significant transaction costs and tax consequences. Moreover, younger family members and next-generation wealth holders are particularly attracted to alternatives exposure. The custom fund facilitates wealth transfer while maintaining assets within the RIA.

Over time, the custom fund becomes the centerpiece of the RIA’s value proposition. This transforms the RIA from a commodity provider of financial planning and public markets access into a specialized institutional manager with differentiated capabilities. Clients transition from viewing the RIA as a service provider to viewing it as their institutional alternatives platform, which fundamentally changes the relationship dynamic. Satisfied custom fund investors become enthusiastic advocates, generating referrals from peers who want similar access to institutional alternatives. Moreover, RIAs with proprietary investment products may experience enhanced client retention due to increased switching costs and differentiated offerings.

Custom Funds as a Competitive Advantage

Most importantly, the custom fund structure aligns perfectly with the long-term trajectory of the wealth management industry. As alternatives continue capturing share from traditional 60/40 portfolios (projected to represent 20-30% of client portfolios by 2030), RIAs must develop institutional-grade capabilities to access these markets effectively. The custom fund structure transforms alternatives from a service add-on into a core competency with sustainable competitive advantages. Rather than managing a multitude of separate alternative allocations with individualized reporting, capital call management, and tax preparation, the RIA manages one vehicle. This approach transforms alternatives from an operational burden and margin pressure into a strategic differentiator and profit center. It converts the RIA from a distributor of third-party products into an institutional investment manager with sustainable competitive advantages.

For forward-thinking RIAs, the proprietary custom fund represents the optimal path to delivering exceptional value to clients while building a more valuable, defensible, and profitable advisory business. The question is not whether to pursue this strategy, but how quickly it can be executed.

About the Author

A practical field guide for evaluating whether your diligence process is built to scale.

Private markets are no longer a side allocation for many RIAs. As exposure grows, so does opportunity flow, scrutiny, and internal complexity. In our conversations, it’s increasingly common to see RIAs allocating north of 20% of client portfolios to alts.

What often surprises firms is not the difficulty of evaluating a single private investment. The challenge shows up later, when volume increases, and the same process is asked to carry more weight than it was designed to handle.

At the same time, the tooling around private markets has proliferated. The opportunity cost of a plentiful vendor set is showing up as a patchwork of point solutions, shared drives, spreadsheets, PDFs, and email threads to manage diligence, documentation, and oversight. Each tool may solve one piece of the problem. Together? They often introduce fragmentation rather than clarity and fragility rather than scalability.

This self-assessment helps you step back and evaluate whether your diligence process is positioned to support where your firm is going based on the learnings of where it has been.

Why this assessment matters

In public markets, scale is largely handled for you. Data is standardized. Performance is visible. Oversight is continuous by default.

Private markets are different. There is no centralized database. Each firm builds its own understanding of the opportunity set over time, through experience, analysis, and repetition.

Teams often discuss diligence in the context of compliance, but in practice, it supports much more:

• Investment committee conviction
• Advisor confidence in client conversations
• Compliance and audit readiness
• Consistency as teams grow and change

RIAs often encounter the natural limits of processes built around fragmented information, manual handoffs, and tools that were not intended to carry context end-to-end.

A self-assessment of your diligence process

As you read each section, ask whether the statements feel true for your firm today.

1. Where does judgment live?

At many firms, a small number of experienced people typically drive diligence quality. Their expertise is real and valuable. Is it portable?

Ask yourself:

• If a key team member were out for a month, could others confidently explain why specific private investments were approved?
• Can you quickly trace how your team identified and weighed risks across different deals?
• Does your process retain how your team made decisions, or mostly the final conclusion?

When diligence context primarily lives in people and one-off documents, it becomes harder for it to travel intact as volume increases. 

The ability to enable real-time readiness through a portable, digital access point that maintains the same quality, perhaps even elevates it, is the difference between your ability to confidently and securely reach and maintain scale with your diligence process. 

2. How durable and reproducible is your diligence?

Reproducibility matters not because outcomes must be perfect, but because the process must be defensible.

“When the SEC looks at an alternative investment, they’re not asking if it was right or wrong. They’re asking: did you do the work and can you show it?”

— Logan Henderson, Co-founder & CEO, Gridline

Ask yourself:

• If asked tomorrow, could you retrieve the complete diligence record for a specific investment without a scramble?
• Are documents, approvals, and rationale easy to locate and clearly connected?
• Would someone outside the original decision process understand the reasoning?

Diligence work often needs to travel further beyond the initial decision and across the firm, supporting advisors, clients, and compliance. When the record is fragmented across tools, inboxes, and individual memory, that travel becomes harder than it needs to be. 

The ability to access a digital, centralized repository that can reproduce the original investment memo and DDQ in real-time can be the difference between always being SEC audit-ready and continuing past practices of chaos and team anxiety. 

3. Does diligence support advisors and clients downstream?

Diligence does not end at the investment committee.

Ask yourself:

• Can advisors easily access and understand the rationale behind an investment?
• How confidently can client questions be answered without redoing analyses?
• Does the same core reasoning show up consistently in advisor and client conversations?

When teams structure diligence well, it becomes an enablement function, not just a gatekeeping step.

Having a standardized investment memo provides a standalone tool for RIAs to independently advise clients and proactively get ahead of potential client questions tied to rationale, strategy, and risk. This means the integrity and output of your diligence process remains intact without burdening investment team members to support advisor education and client conversations.

4. What happens as volume continues to increase?

This is the forward-looking question. If you’ve made it here and you’re batting a thousand, this may be the one question that triggers a pause if what you’re doing today isn’t prepared to handle the volume of the future. 

Ask yourself:

• If your private market exposure doubled over the next two years, what would break first?
• Would headcount need to scale to keep up?
• Would technology need to be adopted?
• Would confidence increase or erode as complexity rises?

Firms that navigate this transition well tend to recognize early that scaling private markets is as much an operating question as an investment one.

To maintain compelling margins, it’s simply not feasible to continue investing in additional bolt-on technology systems and investment team personnel to solve the problem. This is inherently the tipping point where RIAs decide to either work with an OCIO group and outsource a portion of their diligence or spend a few years investing in building an in-house AI engine to add more latitude and velocity to existing processes. Both options add considerable near-term cost to protect the long-term horizon for the firm. 

Why infrastructure becomes unavoidable at scale

At a certain point, these shifts run into a structural constraint.

Point solutions, shared drives, and manual workflows can support individual steps, but they struggle to support the entire lifecycle of diligence without additional coordination or manual effort.

In a 2025 industry survey of financial professionals, 56% reported that investment due diligence is a major time-consuming operational challenge. An equal share cited ongoing servicing tasks, such as managing capital calls, documentation, and fund communications, as significant drains on their time and resources. This reflects what many advisors experience first-hand: the administrative load around private investments scales faster than the tools they use to support it.

This is where many firms begin to look for end-to-end infrastructure, not because they want new technology, but because they want:

• One place where diligence lives
• A persistent, auditable record of decisions
• Context that survives team growth and time
• Systems that absorb complexity instead of multiplying it

For firms operating at scale, infrastructure is less about efficiency and more about durability.

“Firms don’t look for systems because they want new technology. They look for them because the coordination work starts to outweigh the investing work.”

— Logan, Co-founder & CEO, Gridline

Closing perspective

Private markets reward long-term thinking. The same is true of the systems that support them.

Firms that pause to evaluate how their diligence process will hold up over time are not being cautious. They are being strategic.

Clarity here does not require immediate change. It’s about seeing where the cracks may form before you’re managing twice as many investments.

About Gridline

Gridline is an end-to-end alternatives management platform built to support how RIAs actually operate private markets at scale. We centralize the full alternatives workflow, from diligence and fund launch through portfolio oversight, reporting, and ongoing operations. This means private investments can be managed with the same clarity and control as public markets.

At the core of the platform is purpose-built infrastructure designed for private assets, paired with AI that strengthens decision-making, preserves institutional knowledge, and creates a durable audit trail over time.

AltComply is Gridline’s AI-powered diligence suite. It helps firms structure, retain, and reuse investment analysis so judgment compounds across opportunities, teams, and time. It supports investment committees, advisors, and compliance from a single source of truth. AltComply streamlines private fund diligence by transforming raw documents into structured, AI-generated insights, investment committee memos, and DDQs, creating a repeatable, auditable process teams can trust. It also includes an AI-powered red flag engine that surfaces non-standard terms and areas requiring closer review within private fund documents, along with an interactive Q&A that allows teams to ask natural-language questions and receive clear, cited answers grounded in the source materials.

For a closer look at how AltComply helps RIAs make diligence repeatable and audit-ready, watch this short walkthrough.

About the Author

While earning his MBA at the University of Virginia’s Darden School of Business, he was Chief Investment Officer of Darden Capital Management. Charles holds an undergraduate degree from the University of North Carolina and is a CFA charterholder.

Common Sticking Points and How Firms Work Through Them in Practice

Closed-end drawdown funds, as white-labeled “custom funds,” are not new. They’ve been part of institutional private market investing for decades, and many RIAs already use them today.

What continues to make them strategic is not novelty. It is leverage.

Private markets have evolved well beyond niche allocations. In 2025, roughly 80% of advisors across channels now include alternatives in accredited client portfolios. Nearly as many expect to increase those allocations this year as private equity, private credit, and other illiquid strategies become core components of diversified wealth portfolios.

“Custom funds” give RIAs a way to bring structure, consistency, and scale to private market investing. Instead of scrambling every time a new opportunity appears, firms can create a repeatable vehicle that aligns with their investment philosophy. This simplifies the client experience and strengthens their position with managers. For some firms, the appeal is negotiating leverage and operational efficiency. For others, it is differentiation and the ability to deliver a more institutional experience to clients. Often, it is all of the above.

I’m Charles Patton, Director of Investments at Gridline. I spend my days talking with RIAs and General Partners and working directly with firms that are launching, running, or refining custom fund strategies. What follows are lessons that surface repeatedly across RIAs of different sizes and stages of growth, but that share an interest in firm differentiation and alpha generation for their clients. Whether you’re an RIA launching your first custom fund or have done so before and are looking to do it better, my hope is that these lessons prove a valuable resource as you further your private market strategy.

---

Gotcha 1: “We’ll just stitch this together ourselves.”

This is often the first moment when enthusiasm meets operational reality.

At a high level, a custom fund feels manageable: form a vehicle, elect managers, raise capital, let it ride. 

What this looks like in practice

• Legal formation sits with one provider.
• Fund administration with another.
• Subscriptions handled somewhere else.
• Performance reporting tracked separately.
• Client documents stored in yet another place.

None of these pieces are inherently problematic on their own. The challenge emerges when the fund moves from setup to live operation and capital starts moving.

Why this trips firms up

The work extends beyond finding vendors. It is managing the handoffs between them. Reconciling data across systems. Making sure subscription information matches capital calls. Catching inconsistencies before clients notice. Over time, the RIA often becomes the integrator, carrying much of the coordination and oversight responsibility. This is true for firms launching their first custom fund and for firms that have done this before but are now trying to scale.

What changes when this is handled well

Firms that move through this successfully tend to reach the same conclusion: fragmentation is the risk. Consolidation is the release valve. When firms design the operating model so the heavy lifting lives in one place, advisors can spend time on portfolio decisions and client conversations rather than coordination.

Gotcha 2: “Putting our name on this elevates the risk.”

Some RIAs perceive that launching a custom fund elevates the brand reputation risk for their firm and individual advisors because the vehicle carries their name and is built specifically for their clients. Yet this is usually precisely why they’re often drawn to the strategy in the first place: market differentiation and well-thought-through asset class allocation. 

What this looks like in practice

While allocating to the most well-known interval funds can feel like a problem solved, this can kick the can down the road should returns remain pedestrian or promised liquidity fail to materialize. When advisors answer their key questions on privates early and align on how their firm is differentiated, the dynamic shifts. What feels like a liability becomes a source of competitive edge.

Why this trips firms up

What’s sometimes less visible is that RIAs are already accountable for private market outcomes through manager selection, portfolio construction, and client guidance, regardless of whether their name is on the fund. The difference with a custom fund is the RIA isn’t beholden to the rigidity of an off-the-shelf third party fund when creating a bespoke bundle of funds or FoF (fund of funds) that’s been structured based on the investment thesis and risk tolerance profile the RIA is comfortable with.

What changes when this is handled well

When firms are clear about how the vehicle will operate and how expectations will be set over time, the focus tends to shift from perceived exposure to intentional ownership of the structure.

Gotcha 3: “Clients are going to be confused, and we’ll spend all our time overcoming objections.”

Most advisors can point to a moment when a client reacted negatively to something unfamiliar. Perhaps it was a capital call, an account value that didn’t move, or a statement that looked nothing like a brokerage report.

What this looks like in practice

During the launch quarter, client questions spike. Advisors find themselves explaining capital calls, why committed capital has not yet been fully deployed, and why early account values or statements do not look like public market reporting.

Why this trips firms up

The fear is not that clients will dislike private markets. It is that the mechanics will overshadow the strategy, especially early on.

What changes when this is handled well

In practice, much of the confusion centers on pacing and expectations. Firms that anticipate this use models to show how capital calls and distributions typically unfold and explain what clients will see before they see it. Once that initial work is done, the model becomes simpler to run and significantly more scalable over time.

Gotcha 4: “We don’t have the team for this.”

Custom funds often feel like something only very large firms can support.

What this looks like in practice

Firms assume launching a custom fund requires significant new headcount to manage subscriptions, documentation, and ongoing administration. The effort starts to feel out of reach, even when investment conviction and client interest are there.

Why this trips firms up

This often brings staffing to the foreground of the decision. In reality, the work is real, but it is concentrated. Most of the effort shows up during the launch quarter, when clients are onboarded, documents are collected, and questions are answered.

What changes when this is handled well

Across firms of all sizes, the gating factor is rarely headcount. It’s clarity. Who owns the process, where documents live, and how information flows once capital starts moving. When those pieces are defined, and the initial work is absorbed, the model becomes far more scalable than managing private investments fund by fund. In practice, firms that navigate this well pair clear internal ownership with an infrastructure partner that absorbs much of the operational lift.

Gotcha 5: “All the good managers are locked up.”

This concern comes up frequently, even among firms that have allocated to private markets for years. That concern isn’t entirely misplaced; some established managers are fully spoken for and may remain that way for some time.

What this looks like in practice

Discussions tend to center on a short list of well-known managers. If access to those names feels limited or unavailable, it can create the impression that the broader opportunity set is closed.

Why this trips firms up

This can make private markets feel like a fixed universe. In reality, some established managers are fully spoken for, but the market itself is constantly changing. Fund sizes grow. Teams evolve. New managers emerge. The dynamics that made a firm exceptional at one scale do not always persist at another.

What changes when this is handled well

Rather than anchoring on a static list of names, firms focus on understanding how manager quality evolves over time and where the next generation of strong managers is emerging. For RIAs in the wealth channel, this creates an opportunity to access strategies and talent that are still early, rather than competing for capacity that may already be fully allocated.

---

How Firms De-Risk the Move as a Whole

Across successful custom fund strategies, a few patterns show up consistently. These are not theoretical best practices. They reflect what I’ve seen work first-hand across firms of different sizes and levels of experience.

1. They model pacing before committing to structure.

Firms model capital calls and distributions in advance, so they understand how cash will move over time and what that means for client portfolio planning.

2. They shape the portfolio with real client input early.

Rather than launching cold, firms have early conversations with a small group of clients to understand preferences, pressure test assumptions, and build alignment before commitments are requested.

3. They align internally before fundraising begins.

Investment leadership takes time to align on philosophy and conviction, so the rationale carries through client conversations, fundraising, and the inevitable questions that surface early on.

4. They treat the launch quarter as front-loaded work, not ongoing friction.

Firms plan for a concentrated period of effort around onboarding, documentation, and education, secure in the knowledge that they are building a more scalable system.

Infrastructure is What Makes All of This Viable at Scale

In practice, many of the perceived risks around custom funds, staffing burden, client confusion, and operational drag come from private investments being bolted onto workflows that were never built to support them. Firms that de-risk the move treat infrastructure as foundational, not ancillary. Onboarding, subscriptions, document management, capital calls, reporting, and performance visibility live in systems designed for private assets, often supported by a dedicated partner that absorbs much of the operational lift.

When that foundation is in place, the complexity of private markets doesn’t disappear; it becomes contained. Responsibilities are clear, effort is front-loaded, and the strategy scales intact rather than becoming more fragile as assets grow.

Closing

Custom funds carry real complexity. In practice, outcomes tend to hinge on whether that complexity is addressed deliberately and supported by the right operating model.

When firms approach these structures with clarity and intention, closed-end drawdown funds become a powerful way to deliver differentiated exposure, strengthen alternatives programs, and offer clients an experience that feels institutional rather than improvised.

Across customers Gridline has partnered with, they’ve noticed increased client buy-in, a higher barrier to exit given the long-lived nature of the funds, and excitement from forward-thinking advisors with a greater variety of tools to use to improve client outcomes. 

That is what it looks like to set a new standard in private market investing.

About Gridline

Gridline is an end-to-end alternatives management platform built to set a new standard for private market investing. We work with RIAs to make private markets as easy to operate as trading stock, without sacrificing rigor or control.

Through our Custom Funds product, Gridline helps RIAs launch and manage closed-end drawdown funds by providing a single platform for fund formation support, subscriptions, capital calls, performance reporting, and ongoing operations. The goal is simple: absorb the operational complexity so advisors can focus on investment decisions and client relationships.

For a closer look at how Gridline supports RIAs launching closed-end drawdown vehicles, you can view our Custom Funds one-pager here.

About the Author

If you’ve ever done work around your house, you’ve already made this decision. You picked a system. Ryobi, DeWalt, or Milwaukee. And once you did, everything got easier.

Because you’re not actually buying a drill. You’re buying the battery. The charger. The compatibility layer behind every tool you’ll use going forward. Once you’re in, every new tool just works. Same batteries, same system, no friction.

That’s interoperability in its simplest form. 

In business, most firms do the opposite. We buy software the way we buy one-off tools. A CRM here. Reporting there. Something for onboarding. Each decision makes sense in isolation. But over time, you don’t build a system. You build a patchwork.

And the cracks start to show. Data lives in different places. Teams spend time reconciling instead of operating. Workflows break at the edges. Every new initiative takes longer than it should. 

The issue is not the tools. It’s the lack of interoperability between them.

A Different Way to Assess Your Stack

The best operators think about this differently. They’re not asking what a tool does. Instead, they’re asking how it connects. Does data move cleanly? Is there a shared source of truth? Do workflows actually run end-to-end? That is where leverage comes from.

At the center of all of it is data. Data is the battery. It powers reporting, decisions, client experience, and increasingly, automation and AI. When it’s fragmented, everything slows down. When it’s unified, everything compounds.

This is where most platforms fall short. They look integrated on the surface, but underneath, data is duplicated, and workflows are stitched together. It feels connected, but it doesn’t operate that way.

A better approach is simpler, but harder to execute. One data model. One system of record. Workflows that run all the way through, not just to the next handoff. Every action feeds the same source of truth.

That is what turns software from a collection of tools into actual infrastructure.

And it unlocks something bigger. The ability to own your platform, your data, and the experience you deliver to clients.

Rethinking the Toolkit

The same way you would never build a garage full of tools that all require different batteries, you shouldn’t build your business that way either.

Interoperability isn’t a feature. It’s the foundation.

The question is: are you building a system, or just adding more tools?

Access to private markets has become easier to talk about.

Evergreen and semi-liquid funds are gaining visibility across the wealth channel. They often emphasize lower minimums, simpler onboarding, and more frequent liquidity windows. For many advisors and clients, that accessibility is appealing, and in some cases, genuinely useful.

At the same time, greater access to private markets can blur an important distinction. The structure used to package a private investment doesn’t change the nature of the underlying assets. It changes how the experience is framed.

Stepping back, it’s worth revisiting what actually drives outcomes in private markets, and what hasn’t changed, even as their packaging multiplies.

A Simple Reality: Private Assets Are Still Illiquid

Liquidity in private markets is typically scheduled, staged, or conditional. Capital is committed, deployed over time, and returned unevenly as investments mature or exit. That rhythm isn’t accidental. It reflects how private companies and assets are built, financed, and realized.

Research has long associated this structure with an illiquidity premium: the possibility of higher returns in exchange for committing capital that can’t be accessed at will. That relationship has been studied for decades, and it remains a foundational concept in private investing.

What varies across structures isn’t the existence of illiquidity. It’s how it’s presented, managed, and experienced.

When Packaging Becomes the Product

Many newer private market structures aim to reduce friction at the point of entry. In the U.S. alone, net assets in semi‑liquid evergreen private equity funds reached approximately $500B. More than half of those vehicles have been launched in the last four years. This illustrates how these newer wrappers are rapidly gaining prominence even though underlying assets remain illiquid. Lower minimums, smoother onboarding, and more frequent liquidity windows can make participation feel more familiar, particularly to investors accustomed to public-market mechanics.

In those cases, the structure is doing important work. It’s shaping expectations, simplifying administration, and broadening distribution.

At the same time, emphasizing ease of access to private markets can shift attention away from how capital is actually deployed and managed once it’s inside the vehicle. Liquidity features are often conditional rather than guaranteed, and their usefulness can depend heavily on market conditions.

In practice, the benefits of smoother packaging tend to accrue most clearly to distribution, making it easier to raise, aggregate, and scale capital. Whether that same structure consistently improves investor outcomes depends on how well it aligns with the strategy and the underlying assets.

What the Wrapper Can Change in Practice

Even when underlying assets appear similar, evergreen packaging introduces structural dynamics that matter over time:

• Cash drag. Semi-liquid funds often need to hold more cash or liquid sleeves to meet redemptions, which can dilute exposure to the underlying strategy.
  
• Adverse selection. The most capacity-constrained or highest-performing managers often remain in closed-end structures, while evergreen vehicles may concentrate in more scalable, more distributable exposures.
  
• Liquidity mismatch risk. When a fund offers quarterly liquidity gates or slow redemptions, advisors must manage the gap between client expectations and structural reality.

These are not flaws; they are tradeoffs. But they tend to surface later, not at the point of entry.

Structure, Experience, and the Long View

The proliferation of new investment wrappers hasn’t altered the fundamental nature of private assets, but it has profoundly reshaped the investor experience. While evergreen structures offer a sense of familiarity to those used to public-market mechanics, they often mask the enduring reality of illiquidity that defines the asset class.

In contrast, closed-end drawdown funds remain the most adaptable ecosystem for private investing. They align the capital commitment and deployment cycle with the actual rhythm of how private companies are built and realized. History reminds us that the depth and liquidity of the U.S. markets are unparalleled, yet the foundation of private markets still requires a staged, intentional approach to capital.

The bottom line is that while the world talks about accessibility, the long view requires a focus on outcomes.

One model presents private markets as a continuously evolving allocation. The other takes the shape of a defined, disciplined program. Neither approach is inherently superior, but each creates a different psychological and financial footprint for the client.

As we navigate periods of acute volatility and shifting asset class expectations, the durability of an investment strategy depends on its alignment with the underlying assets. Whether capital flows to public or private markets, the reign of disciplined portfolio construction continues.

This brings us back to the foundational question that must be answered before the next decade of market cycles. What kind of outcome are we building through these various wrappers?

The answer lies not in the packaging itself, but in seeing the forest through the trees. The most successful programs will be those where the structure directly extends the investment philosophy, rather than distracting from it.

About Gridline

Gridline is an end-to-end alternatives management platform built to set a new standard for private market investing. We work with RIAs to make private markets as easy to operate as trading stock, without sacrificing rigor or control.

Through our Custom Funds offering, Gridline helps RIAs launch and manage closed-end drawdown funds. We provide a single platform for fund formation coordination, investor onboarding and subscription processing (including KYC/AML), capital call and distribution management, fund administration and investor reporting, centralized investor / advisor communications, and ongoing fund operations. We operate as the manager and system of record for the fund. Our platform includes structured compliance workflows, custodial connectivity and downstream data integrations, and full auditability across all transaction activity. The goal is simple: absorb the operational complexity so advisors can focus on investment decisions and client relationships.

For a closer look at how Gridline supports RIAs launching closed-end drawdown vehicles, you can view the Custom Funds one-pager here.

About the Author

Prior to joining Gridline, Carson served as a Senior Wealth Manager at BNY Wealth, where he advised clients on investment strategy, asset allocation, and holistic wealth planning. Earlier in his career, he held roles at Bank of America Private Bank and PwC, building a foundation in portfolio management, financial analysis, and client advisory. Carson holds a BBA and Master of Accounting from the University of Georgia and is a CFA charterholder.

Investment diligence does not end with an investment committee decision. In modern advisory firms, it is the beginning of a longer chain of responsibility.

Once an investment is approved, advisors need to understand how it fits within a portfolio. Clients need to understand why it is appropriate for their objectives and risk tolerance. Compliance teams need to be able to demonstrate that the recommendation was grounded in a defensible process. Regulators expect to see evidence of all three.

For diligence to create value beyond the committee room, the information behind the decision has to move cleanly from one group to the next. How that information travels—or fails to—is where many firms begin to feel friction.

Where the Chain Breaks

When diligence artifacts are fragmented, this chain breaks.

Too often, investment analysis lives in one system, advisor education in another, and compliance documentation somewhere else entirely. The result is friction, inconsistency, and risk. Not because decisions are poor, but because the information behind those decisions does not travel intact across the firm.

Why this Matters for Compliance and Trust

Deloitte’s 2025 Investment Management Regulatory Outlook highlights that firms face a complex and evolving regulatory environment requiring vigilant compliance and robust processes, including for areas like records retention and oversight, underscoring why efficient documentation workflows are increasingly critical. 

The takeaway? Regulators are not looking for perfection. They are looking for evidence of process.

Firms that can clearly show how risks were identified, how decisions were reached, and how clients were educated operate from a position of strength. That strength comes from being able to reproduce the full story of an investment without having to reconstruct it under pressure.

Diligence as Infrastructure

Some firms design diligence as an internal enablement engine, a structured analysis that supports not just investment committee decisions, but also advisor conversations and client education, with judgment that travels intact across the organization. The goal isn’t speed, but continuity: preserving investment context through systems that reduce noise, maintain standards, and mitigate risk as scale increases.

Ultimately, diligence creates value only when it is understood, explainable, and repeatable. It must also be transferable.

Firms that recognize this do not treat diligence as a gatekeeping function. They treat it as infrastructure, supporting advisors, protecting clients, and reinforcing trust at every level of the organization.

About Gridline

Gridline is an end-to-end alternatives management platform built to support how RIAs actually operate private markets at scale. We centralize the full alternatives workflow—from diligence and fund launch through portfolio oversight, reporting, and ongoing operations—so private investments can be managed with the same clarity and control as public markets.

At the core of the platform is purpose-built infrastructure designed for private assets, paired with AI that strengthens decision-making, preserves institutional knowledge, and creates a durable audit trail over time.

AltComply is Gridline’s AI-powered diligence infrastructure. It helps firms structure, retain, and reuse investment analysis so judgment compounds across opportunities, teams, and time, supporting investment committees, advisors, and compliance from a single source of truth. AltComply streamlines private fund diligence by transforming raw documents into structured, AI-generated insights, investment committee memos, and DDQs, creating a repeatable, auditable process teams can trust. It also includes an AI-powered red flag engine that surfaces non-standard terms and areas requiring closer review within private fund documents, along with an interactive Q&A that allows teams to ask natural-language questions and receive clear, cited answers grounded in the source materials.

The result? RIAs that are empowered to move faster and expand coverage while improving confidence through a standardized diligence record. That’s what it means to set a new standard in alternative investing. 

For a closer look at how Gridline supports RIAs with private market diligence, watch the AltComply demo.