# EnterpriseContextGraph Procurement Starter Pack

Version: 0.1 draft  
Prepared: July 22, 2026

> This starter pack is not legal advice, an approved justification, or a determination that EnterpriseContextGraph is the only responsible source. The buyer must select the applicable authority, conduct current market research, evaluate alternatives, obtain approvals, establish price reasonableness, and consult procurement counsel.

## 1. Mission-need worksheet

- Consequential decision or workflow:
- Business and technical owner:
- Financial, security, legal, operational, customer, or physical consequence:
- Human, agent, workload, and delegated authority involved:
- Systems and sources used today:
- Current authoritative source by required field:
- Current evidence requirements:
- Current permission model:
- Required freshness by source:
- Current reconstruction time:
- Known contradictions or near misses:
- Retention, audit, legal-hold, and residency obligations:
- Target production date:
- Measurable outcome:

## 2. Essential-requirements matrix

Classify every row as mission-essential, security-essential, interoperability-essential, schedule-essential, desirable, or future option.

| Requirement | Classification | Mission rationale | Acceptance test | Evidence |
| --- | --- | --- | --- | --- |
| Structured Context Request |  |  |  |  |
| Human, agent, workload, delegation, and purpose binding |  |  |  |  |
| Source-ACL and disclosure-policy enforcement |  |  |  |  |
| Valid-time and known-at-time reconstruction |  |  |  |  |
| Field- and decision-scoped source authority |  |  |  |  |
| Freshness contracts |  |  |  |  |
| Mandatory evidence evaluation |  |  |  |  |
| Contradiction and gap preservation |  |  |  |  |
| Versioned Evidence Manifest |  |  |  |  |
| Signed portable Context Bundle |  |  |  |  |
| Detached verification |  |  |  |  |
| Declared replay fidelity |  |  |  |  |
| Export and transition |  |  |  |  |

## 3. Common vendor demonstration

Use the same scenario for every vendor, combination, integrator, and internal-build option:

1. A designated user and agent request evidence for a vendor bank-account change.
2. Sources contain an ERP vendor master, signed contract, prior payment, email attachment, recent change event, requester identity, and policy.
3. The email conflicts with the authoritative ERP record.
4. One document is visible to the human but prohibited for the agent’s purpose.
5. Independent verification is mandatory and missing.
6. An assertion was valid before the platform observed it.
7. The policy changes between requested dates.
8. The evaluator changes principal, valid time, known-at time, and policy.
9. The system must resolve, manifest, sign, verify, replay, and link the evidence state to downstream authorization.

Score each capability as: meets natively, meets with configuration, meets with documented extension, requires custom development, does not meet, or not demonstrated.

## 4. Alternatives questionnaire

Evaluate:

- Enterprise search and work AI.
- Knowledge graphs and graph databases.
- Data catalogs and lineage.
- Authorization and policy engines.
- Agent observability and AI governance.
- Operational ontology and workflow platforms.
- Systems-integrator development.
- Combined best-of-breed stack.
- Internal build.

For each option, record current capability, custom work, schedule, security boundaries, evidence semantics, operating responsibility, total cost, portability, and transition risk.

## 5. Decision Context Audit scope

- Approve one bounded decision type.
- Inventory systems, sources, identities, permissions, and policies.
- Reconstruct one recent decision.
- Define authority, freshness, and mandatory evidence.
- Measure gaps, contradictions, unauthorized retrieval, and reconstruction time.
- Produce the first disclosure-safe Evidence Manifest.
- Define security architecture, acceptance tests, and pilot plan.

## 6. Statement-of-work outline

### Phase 0 — Discovery and evidence architecture

Deliver: audit, source inventory, permission map, authority rules, freshness contracts, evidence profile, threat model, target architecture, and plan.

### Phase 1 — Design-partner proof

Deliver: selected connectors, identity mapping, ACL tests, versioned evidence, Context Request, Manifest, Bundle, signing, verification, explorer, replay, and downstream adapter.

### Phase 2 — Production pilot

Deliver: production deployment, keys, networking, monitoring, connector health, revocation propagation, audit export, runbooks, training, and support.

## 7. Acceptance matrix

| Deliverable | Evidence of completion | Acceptance authority |
| --- | --- | --- |
| Context Request schema | Versioned schema and tests | Technical lead |
| Permission resolution | ACL parity and negative tests | Security / identity lead |
| Temporal evidence | Valid-time and known-at scenarios | Data architecture lead |
| Evidence Manifest | Required dispositions and deterministic digest | Program / audit lead |
| Context Bundle | Signature, verification, warnings, and obligations | Security lead |
| Contradiction engine | Scripted conflict preserved | Business owner |
| Evidence-gap engine | Missing mandatory item declared | Risk owner |
| Replay | Fidelity declaration and comparison | Audit lead |
| Deployment | Security and operational readiness review | Authorizing authority |

## 8. Security questionnaire

- How are humans, agents, workloads, connectors, and signing services authenticated separately?
- How are connector credentials isolated from model-facing services?
- How are tenant, region, network, encryption, and key boundaries enforced?
- How are ACL parity, nested groups, revocation, field redaction, and purpose restrictions tested?
- What fails closed when permission or source state is uncertain?
- How are source versions, policies, transformations, digests, and signatures preserved?
- How are deletion, legal hold, retention, historical redisclosure, and replay handled?
- Which components can run in a customer VPC or customer-controlled environment?
- What audit, incident, vulnerability, recovery, and transition commitments apply?

## 9. Price and volume worksheet

Record platform, environments, connectors, governed resolutions, signed Bundles, retention, replay, deployment, key management, support, implementation, training, and transition. Compare commercial pricing, prior transactions, internal build, combined alternatives, integration, cost of delay, outcome assumptions, options, renewal caps, service credits, and portability.

## 10. Justification outline

Use only after the buyer completes market research and selects the applicable authority:

1. Identification and scope.
2. Exact acquisition authority.
3. Neutral mission need and minimum requirement.
4. Supplies and services.
5. Market-research methods, dates, sources, and findings.
6. Common demonstration results.
7. Alternative and internal-build analysis.
8. Substantiated unique qualifications, if any.
9. Responsibility evidence.
10. Fair-and-reasonable price analysis.
11. Competition-enabling and transition actions.
12. Certifications, approvals, counsel, and public/proprietary review.

Remove all placeholders and unsupported claims before approval. Reassess the market before renewal or expansion.