WEBVTT

1
00:00:00.000 --> 00:00:03.297
An interface plan becomes useful
when every connection and limit

2
00:00:03.355 --> 00:00:06.780
has an identifiable source.
In this lesson, we will read

3
00:00:06.815 --> 00:00:10.565
the exact board and sensor documents
and build a small constraints table.

4
00:00:11.076 --> 00:00:13.792
Open checkpoint four in
a new exercise folder.

5
00:00:14.396 --> 00:00:17.879
You need the project documents
and a browser or document viewer.

6
00:00:18.204 --> 00:00:22.093
You do not need the optional hardware
on your desk. Begin with identity,

7
00:00:22.210 --> 00:00:23.881
before looking for a pin number.

8
00:00:24.125 --> 00:00:28.711
Our documented example is the
Adafruit Feather ESP32-S3,

9
00:00:28.862 --> 00:00:33.471
product five four seven seven, with four
megabytes of flash and two megabytes

10
00:00:33.506 --> 00:00:37.094
of PSRAM. The product description
distinguishes this from another memory

11
00:00:37.140 --> 00:00:40.101
variant. Keep that distinction
in the project record because

12
00:00:40.124 --> 00:00:43.828
a familiar family name is not enough
to choose the build configuration.

13
00:00:44.211 --> 00:00:46.869
Now separate the objects
in the proposed system.

14
00:00:47.194 --> 00:00:49.876
There is a sensor chip, a
breakout that contains it,

15
00:00:49.992 --> 00:00:54.149
a host development board, and a software
package that supports the selected board.

16
00:00:54.393 --> 00:00:57.771
Each has a different reference.
A chip datasheet cannot tell

17
00:00:57.829 --> 00:01:01.069
you every connection on a carrier
board. A board guide cannot

18
00:01:01.127 --> 00:01:04.528
automatically establish the
assumptions of every library version.

19
00:01:05.039 --> 00:01:08.673
Open the hardware reference in the
project and follow its primary links.

20
00:01:08.999 --> 00:01:11.355
Record the document
title, relevant section,

21
00:01:11.390 --> 00:01:13.701
and revision or pinned
version when available.

22
00:01:14.026 --> 00:01:16.464
An access date is also
useful for a web page,

23
00:01:16.615 --> 00:01:20.353
but it has a limited meaning. It says
when the page was checked. It does not

24
00:01:20.400 --> 00:01:24.312
identify the manufacturing revision of
a physical board you have not inspected.

25
00:01:24.638 --> 00:01:26.112
Consider a supply statement.

26
00:01:26.391 --> 00:01:29.827
The bare sensor's supply limits
describe its silicon connection.

27
00:01:30.210 --> 00:01:32.544
The breakout may include
supporting circuitry,

28
00:01:32.637 --> 00:01:35.818
such as a regulator, and describe
a different input connection.

29
00:01:36.421 --> 00:01:40.020
Both documents can be correct while
their numbers have different scopes.

30
00:01:40.531 --> 00:01:42.609
The review question is
therefore not simply

31
00:01:42.656 --> 00:01:46.394
whether two numbers match. It is
whether they describe the same object

32
00:01:46.441 --> 00:01:49.808
and connection point. This
distinction is particularly important

33
00:01:49.855 --> 00:01:53.291
when an assistant combines several
references into one answer.

34
00:01:53.802 --> 00:01:57.378
A fluent summary can omit the
object name and leave a number

35
00:01:57.448 --> 00:02:01.418
that appears universally applicable.
Keep the object in the table.

36
00:02:01.743 --> 00:02:06.317
If the source says breakout input,
write breakout input. Do not shorten

37
00:02:06.375 --> 00:02:10.195
it to sensor voltage and then apply it
somewhere the source did not address.

38
00:02:10.578 --> 00:02:13.411
Check population separately
from a drawing label.

39
00:02:13.794 --> 00:02:16.941
The Feather guide describes
a BME280 footprint.

40
00:02:17.184 --> 00:02:21.294
A footprint identifies a place a
component could occupy; it does not

41
00:02:21.340 --> 00:02:25.578
establish that your example includes
the component. Our optional sensor

42
00:02:25.659 --> 00:02:29.514
is a separate breakout. An assistant
should not turn the presence of a label

43
00:02:29.595 --> 00:02:33.578
into a claim that an unseen assembly
already contains a working sensor.

44
00:02:33.961 --> 00:02:36.469
Ask the constraints skill
for a concise table.

45
00:02:36.794 --> 00:02:40.439
The columns are claim, value
and unit, source section,

46
00:02:40.590 --> 00:02:43.539
confidence or missing
information, and consequence.

47
00:02:43.864 --> 00:02:46.476
Keep the request focused
on the interface decision.

48
00:02:46.801 --> 00:02:49.390
You are not asking for
a driver implementation,

49
00:02:49.483 --> 00:02:52.037
a shopping list, or a wiring operation.

50
00:02:52.246 --> 00:02:56.554
A bounded output is easier to compare
with the actual manufacturer sections.

51
00:02:56.832 --> 00:02:59.526
Review the first factual
row before moving on.

52
00:02:59.770 --> 00:03:04.506
Find its cited section and check the
exact object, value, unit, and conditions.

53
00:03:04.785 --> 00:03:07.896
Then read the consequence
as a project interpretation.

54
00:03:08.279 --> 00:03:10.532
A source can establish a memory variant;

55
00:03:10.776 --> 00:03:14.119
choosing the corresponding recorded
target is our design action.

56
00:03:14.502 --> 00:03:16.708
Keeping those roles
visible prevents a table

57
00:03:16.743 --> 00:03:20.227
from making the source appear to
endorse every decision we make.

58
00:03:20.610 --> 00:03:24.743
Units travel with values. Our original
teaching note says the reporting

59
00:03:24.789 --> 00:03:28.481
interval is one thousand
milliseconds, which is one second.

60
00:03:28.806 --> 00:03:32.882
A summary that changes this to one
thousand seconds is wrong even though

61
00:03:32.905 --> 00:03:37.073
the same digits appear. The
compiler may accept either number.

62
00:03:37.282 --> 00:03:41.299
A unit mistake must therefore be caught
in the requirement and interpretation,

63
00:03:41.508 --> 00:03:44.445
not assumed to disappear
during a successful build.

64
00:03:44.770 --> 00:03:46.721
Conditions matter in the same way.

65
00:03:47.104 --> 00:03:50.784
A typical value is not
automatically a guaranteed maximum.

66
00:03:51.063 --> 00:03:54.883
An operating range is not an
accuracy claim. A representable

67
00:03:54.929 --> 00:03:58.946
increment is not proof that a physical
measurement is correct to that increment.

68
00:03:59.271 --> 00:04:02.162
When a source includes a
condition, preserve it beside

69
00:04:02.186 --> 00:04:06.342
the extracted number rather than hiding it
in a paragraph the next reader might miss.

70
00:04:06.783 --> 00:04:10.754
Include an explicit unknown in
the table. Physical revision

71
00:04:10.823 --> 00:04:14.678
not observed is a useful statement
when no physical inspection happened.

72
00:04:15.061 --> 00:04:18.614
A pin absent from the supplied
material should remain unresolved.

73
00:04:19.055 --> 00:04:22.143
Explain which decision that
missing evidence affects and what

74
00:04:22.178 --> 00:04:26.404
would resolve it. This is more actionable
than a vague request to check everything,

75
00:04:26.683 --> 00:04:29.724
and more honest than filling the
cell from a familiar example.

76
00:04:30.235 --> 00:04:34.589
If two sources conflict, retain both
identities and describe the disagreement.

77
00:04:35.193 --> 00:04:39.361
Do not average incompatible values or
choose whichever appears more familiar.

78
00:04:39.802 --> 00:04:43.447
Determine which source applies to the
exact variant and pinned software.

79
00:04:43.958 --> 00:04:46.094
If the necessary section is unavailable,

80
00:04:46.338 --> 00:04:50.007
keep the relevant decision open.
Other supported parts of the plan

81
00:04:50.076 --> 00:04:53.234
can still be completed while
that question remains explicit.

82
00:04:53.618 --> 00:04:57.077
Your exercise includes a proposal
that mixes these mistakes.

83
00:04:57.460 --> 00:05:01.454
It treats all variants as equivalent,
mistakes a footprint for a populated

84
00:05:01.512 --> 00:05:05.924
sensor, transfers a breakout statement
to a bare chip, and loses a time unit.

85
00:05:06.621 --> 00:05:10.289
Mark each claim before rewriting
the proposal. This makes the review

86
00:05:10.347 --> 00:05:13.912
traceable: the correction should
follow from the identified evidence,

87
00:05:14.156 --> 00:05:16.791
not merely sound more cautious
than the first version.

88
00:05:17.232 --> 00:05:19.926
Preserve any actual
skill response you use.

89
00:05:20.367 --> 00:05:24.303
A correctly packaged skill is not proof
that it selected the right sources

90
00:05:24.628 --> 00:05:28.401
or extracted every value accurately.
If the tool cannot run,

91
00:05:28.517 --> 00:05:33.196
complete the documentary review manually
and record the model evaluation as open.

92
00:05:33.707 --> 00:05:37.213
Do not manufacture a conversation
to make the lesson look finished.

93
00:05:37.654 --> 00:05:41.300
A manual source check and an agent
behavior check are different records.

94
00:05:41.811 --> 00:05:45.283
Finish with four to six reviewed
rows and a short corrected proposal.

95
00:05:45.979 --> 00:05:48.673
Another engineer should be
able to open each source,

96
00:05:48.882 --> 00:05:53.224
understand the object it describes, and
see the consequence for this project.

97
00:05:53.665 --> 00:05:56.846
The next lesson turns that
table into an interface plan.

98
00:05:57.543 --> 00:05:59.864
We will continue to keep
documentary support,

99
00:06:00.108 --> 00:06:03.301
software execution, and
physical observation distinct,

100
00:06:03.684 --> 00:06:08.177
so progress in one category never
becomes an unsupported claim in another.