Skip to main content
View Markdown ↗

Copy this page

Select and copy the Markdown below, then paste it into your LLM.

Platform data model

Use the Platform to connect a change to the requirements it must meet and the evidence used to evaluate it. This is a conceptual model of the main records, not a database schema or a claim that every relationship is one-to-one.

A product in the Platform represents your software or system. It is different from the TestifySec product family: Platform, CI/lock, and Pushgate.

Products and repositories

Tenant and team access define which records a user or service can reach. A product groups relevant repositories and assessment work. The same repository can participate in more than one product, so a display name or product grouping alone is not an authoritative repository identity.

A product groups repository links and assessment work. Bindings and gate assignments select policy releases. A bounded decision refers to evidence, policy, and repository context. Control mappings relate results to assessments. The diagram is conceptual and does not specify database cardinalities.

Scroll horizontally to explore the diagram, or open the full-size SVG.

Platform records and relationships. A product groups repository links and assessment work. Bindings and gate assignments select policy releases. A bounded decision refers to evidence, policy, and repository context. Control mappings relate results to assessments. The diagram is conceptual and does not specify database cardinalities.
Open full-size SVG ↗Download DOT source
Diagram source (Graphviz / DOT)
digraph Platform {
  rankdir=TB;
  nodesep=0.65;
  ranksep=0.7;
  tenant [label="Tenant and team access"];
  product [label="Your product"];
  repository [label="Repository connection"];
  binding [label="Product policy binding"];
  assignment [label="Pushgate assignment"];
  release [label="Exact policy release",fillcolor="#fff3dd"];
  evidence [label="Signed evidence"];
  decision [label="Bounded policy decision",fillcolor="#fff3dd"];
  control [label="Technical-control assessment"];
  tenant -> product [label="scopes access"];
  product -> repository [label="repository\nlinks"];
  product -> binding [label="policy\nscope"];
  repository -> assignment [label="gate configuration"];
  binding -> release [label="selects"];
  assignment -> release [label="selects"];
  release -> decision [label="requirements"];
  evidence -> decision [label="evaluated input"];
  repository -> decision [label="request context"];
  evidence -> control [label="mapped scoped results"];
}

Keep the records distinct

RecordPurposeDo not confuse it with
ProductGroups your software, repository links, and assessment work.A single repository or a commercial subscription tier.
Repository connectionIdentifies the connected repository within its host and tenant context.A mutable Git remote string supplied by a client.
Policy definition and releaseIdentifies the policy and the exact signed release to evaluate.A display name, tag, or latest selector.
Product policy bindingApplies an exact release to a product or a scoped repository in that product.The separate act of changing a Pushgate repository assignment.
Pushgate repository assignmentSelects the repository's gate policy under the required activation rules.Policy authorship or publication.
Signed attestationRecords a producer's statements about an execution, subject, or result.Proof that the producer was honest or that arbitrary code is safe.
Policy decisionRecords evaluation of bounded evidence against selected requirements.Evidence that the upstream Git host applied the push.
Technical-control mappingConnects relevant results to an assessment of a technical control.Automatic certification or satisfaction of an entire framework.
Preparing, signing, publishing, and activating a policy are distinct acts. Activation selects an exact release for a product binding or repository assignment. Evaluation uses the applicable activated requirements; publication alone does not activate them.

Scroll horizontally to explore the diagram, or open the full-size SVG.

Policy release and activation. Preparing, signing, publishing, and activating a policy are distinct acts. Activation selects an exact release for a product binding or repository assignment. Evaluation uses the applicable activated requirements; publication alone does not activate them.
Open full-size SVG ↗Download Mermaid source
Diagram source (Mermaid)
flowchart TB
  D[Prepare policy] --> S[Sign exact policy bytes]
  S --> P[Publish immutable release]
  P --> A[Review and activate exact release]
  A --> B[Product policy binding]
  A --> G[Pushgate repository assignment]
  B --> E[Evaluate applicable requirements]
  G --> E

Follow one change

  1. CI/lock captures the configured workflow and produces signed evidence.
  2. The Platform evaluates the evidence against the selected policy release and authoritative repository context.
  3. Pushgate uses the decision for the push being checked.
  4. Reviewers can inspect the evidence, requirements, and decision. Delivery observations remain separate from the policy result.

Publishing a signed policy release and activating it are distinct operations. A product binding and a Pushgate assignment are also distinct mutations. Follow the policy assignment documentation for the supported activation path in your deployed release.

Map technical results to controls

Use the results of remediation checks, configuration tests, or recovery rehearsals as scoped evidence for an assessment. Keep the test, result, applicable control, mapping, and assessment scope connected. A successful result can support a control assessment without establishing that the whole control or framework is satisfied.

Continue with system architecture and the trust model and evidence limits.